Created attachment 231940 [details] diff against the ports tree Base has had C.UTF-8 since 2018 and switched to it in base 09ef995baf45. Switching the ports tree to it should largely be a NOP, with exception to one scenario: building in poudriere under qemu-user-static with native-xtools. native-xtools will use statically linked tar(1) for the host, so it can't use dlopen() -- preventing it from being able to use, e.g., iconv. Switching to C.UTF-8 fixes statically linked tar's ability to extract when paths contain UTF-8 chars.
In my own mass rebuild after the latest __FreeBSD_version bump, java/apache-commons-httplib fails during stage due to an ISO8859-1 file. In theory it should have also failed with C.
New failures logs on 12.2 amd64: http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/ireport-3.7.6_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/simavr-1.7_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/doomsday-2.3.1_4.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/xblast-2.10.4_18.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/ja-today-2.12_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/apache-commons-httpclient-3.1_2.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/smokeping-2.8.2_1.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/bibtool-2.68.log http://package18.nyi.freebsd.org/data/122amd64-default-foo/2022-02-19_21h08m46s/logs/errors/linuxdoc-tools-0.9.82.log Around 130 ports were skipped due to those new failures
New failures logs on 13.0 i386: http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/ncid-1.11.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/ireport-3.7.6_1.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/doomsday-2.3.1_4.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/xblast-2.10.4_18.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/ja-today-2.12_2.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/apache-commons-httpclient-3.1_2.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/smokeping-2.8.2_1.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/bibtool-2.68.log http://package23.nyi.freebsd.org/data/130i386-default-foo/2022-02-19_22h11m30s/logs/errors/linuxdoc-tools-0.9.82.log
Apache HttpComponents maintainer here: Commons HttpClient is VERY VERY dead. I guess only JMeter depends on it. Even 4.5.x is overhauled by 5.x. There are two options: 1) Use JAR from Maven Central instead of compiling yourself with Ant, see here: https://lists.freebsd.org/archives/freebsd-ports/2021-December/001159.html 2) Add an explicit encoding for https://ant.apache.org/manual/Tasks/javac.html
(In reply to Michael Osipov from comment #4) 123 ports depend on java/apache-commons-httpclient
(In reply to Antoine Brodin from comment #5) Which? osipovmi@deblndw011x:/usr/ports $ grep -r --include='**/Makefile*' java/apache-commons-httpclient . ./editors/libreoffice/Makefile: ${JAVAJARDIR}/commons-httpclient.jar:java/apache-commons-httpclient \ ./editors/openoffice-4/Makefile: ${JAVALIBDIR}/commons-httpclient.jar:java/apache-commons-httpclient \ ./editors/openoffice-devel/Makefile: ${JAVALIBDIR}/commons-httpclient.jar:java/apache-commons-httpclient ./editors/libreoffice6/Makefile: ${JAVAJARDIR}/commons-httpclient.jar:java/apache-commons-httpclient \ ./www/jmeter/Makefile: ${JAVALIBDIR}/commons-httpclient.jar:java/apache-commons-httpclient
Hey, sorry for stalling on this. I'm trying to decide if it's worth doing, vs. working out if we can build a static libiconv and baking all of it into xtools' tar. I suspect the latter is a better idea...
(In reply to Kyle Evans from comment #7) A problem with use of iconv by native-xtools is that it is missing a native copy of data files in /usr/share/i18n. These files depend on the architecture's byte order.
(In reply to Tijl Coosemans from comment #8) AFAICT both csmapper and esdb are pretty strict about byteswapping. Which aspect isn't agnostic?
(In reply to Kyle Evans from comment #9) You are right. It's /usr/share/locale, not /usr/share/i18n. More specifically the collation and ctype data which are generated by localedef(1). And C.UTF-8 has its own ctype data.
(In reply to Tijl Coosemans from comment #10) It occurs to me that I'm actually not; htonl() and whatnot are still based on the host architecture. It'll work for the vast majority of cases, but it's not reliable.