I noticed the problem when aegisub-3.2.2 failed to link. Some investigation showed that /usr/local/lib/libboost_locale.so (from boost-libs-1.55.0_4) has unresolved references to libiconv{,_open,_close} Further investigation shows that the configure part of boost-libs finds iconv in libc, but when compiling codepage.cpp, it picks up libiconv-1.14_6 (when installed of course). One solution to this problem is to change the configure part of boost-libs to first probe for external iconv libraries and then for internal ones.
Wanted to note here that I ran into the exact same issue when trying to update games/wesnoth - linking failures against the libboost_locale library indicating that libiconv_open and libiconf_close don't exist (I think, libiconv too). I was able to duplicate the issue on a brand new 10.1 VM with nothing installed, using -DBATCH. Older versions (using portdowngrade) also now fail. As a workaround, if I disable the 'ICU' configuration option then games/wesnoth does build, install, and run. I assume that this is an issue that will affect all 10.1 (and probably 10.0) users, as (I think) there is a iconv library in the base system and I am able to duplicate on a clean 10.1 machine.
It appears that if I install boost-libs via 'pkg install boost-libs', nm -D /usr/local/lib/libboost_locale.so | grep iconv | grep close outputs __bsd_iconv_close (sorry for the formatting, I don't have cut/paste against the VM where I did this) but if I run that against a ports build, it outputs U libiconv_close ...so the status of boost-libs package build vs. ports build is suspect.
I tried a ports build on a clean VM - if I do that build, then boost_locale.so links against libiconv_close and others. If I remove libiconv, and build again, it links against __bsd_iconv_close and others. This explains the port/poudriere behavior, as I think that maybe libiconv is a build dependency and doesn't get installed when building boost via poudriere. __bsd_iconv_close and others appears to be provided by libc on 10.1. libiconv_close and others appears to be provided by /usr/local/lib/libiconv.so. Seems that boost-libs should link against one or the other, likely the ports libiconv, since pre-10 systems don't have iconv built in...
Can you try boost-libs r398027?
On 10.2 r398027 gives: make: "/usr/ports/devel/boost-libs/Makefile" line 33: Malformed conditional (${PORT_OPTIONS:MICU}) make: "/usr/ports/Mk/bsd.ssp.mk" line 7: Malformed conditional (${OSVERSION} < 1000036 && ${ARCH} == i386) make: "/usr/ports/Mk/bsd.ssp.mk" line 20: Malformed conditional (!defined(SSP_UNSAFE) && (${ARCH} == i386 || ${ARCH} == amd64)) make: "/usr/ports/Mk/bsd.port.mk" line 1623: Malformed conditional (${ARCH} == "amd64" || ${ARCH} =="ia64") make: "/usr/ports/Mk/bsd.port.mk" line 1652: Malformed conditional (${WITH_PKG} == devel) make: "/usr/ports/Mk/bsd.port.mk" line 2069: Malformed conditional (${PREFIX} == /usr) make: "/usr/ports/Mk/bsd.port.mk" line 2620: Malformed conditional (${PREFIX} == /usr) make: "/usr/ports/Mk/bsd.port.mk" line 2633: Malformed conditional (${PREFIX} == /usr) make: "/usr/ports/Mk/bsd.port.mk" line 3279: Malformed conditional (${OSVERSION} >= 1000000 && !defined(WITHOUT_FBSD10_FIX)) make: "/usr/ports/Mk/bsd.port.mk" line 3576: Malformed conditional (defined(NO_MTREE) || ${PREFIX} != ${LOCALBASE}) make: "/usr/ports/Mk/bsd.port.mk" line 3831: Malformed conditional (${UID} != 0 && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 4843: Malformed conditional ((${PREFIX} != ${LOCALBASE} && ${PREFIX} != ${LINUXBASE} && ${PREFIX} != "/usr" && !defined(NO_PREFIX_RMDIR))) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Uextract:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Upatch:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Uconfigure:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Ubuild:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Ustage:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Uinstall:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: "/usr/ports/Mk/bsd.port.mk" line 5683: Malformed conditional (${UID} != 0 && defined(_${:Upackage:tu}_REAL_SUSEQ) && !defined(INSTALL_AS_USER)) make: Fatal errors encountered -- cannot continue
That looks like something is broken in your copy of the ports framework. Is ports/Mk up to date? That said, I don't think that r398027 will help with this problem. The fixes in that are only for the !ICU case. The question in my mind is why boost is even doing anything with iconv when the ICU option is enabled. It builds fine on FreeBSD 9.3, which doesn't have iconv in libc. % nm -D /usr/local/lib/libboost_locale.so | grep iconv I see that it's "configure" does find iconv in libc on FreeBSD 10: - iconv (libc) : yes - icu : yes There may be a way to get it to ignore iconv if ICU is enabled, or I may be able to force it to ignore the ports iconv even if it is present. Going the other way is undesirable as a default because that would always mean an extra dependency, and doing something automatic causes problems because the results are inconsistent because they depend on the build environment.
The one I got from in my ports tree (398060) builds fine. I have never seen a port fail with errors in the main Makefile before. The problem is that libs/locale/build/Jamfile.v2 first tests for the libc iconv and takes it if it finds it. Swapping the order of the test should fix the issue. I don't know enough about the syntax of the Jamfiles, so I just edit out that part if I need to build a version that works.
I you link to an external library without declaring it as a LIB_DEPENDS, there is nothing that prevents that library from being removed and breaking boost. Also, if that library has it's version bumped, you won't know that you need to rebuild boost, and it will just break. There is nothing wrong with boost using the base iconv implementation in base. If there was, then the package builders would blow up when building multimedia/aegisub and games/wesnoth, but portsmon isn't showing any build failures.
Created attachment 161512 [details] patch to disable use of iconv when the ICU option is disabled Try the attached patch against boost-libs/Makefile r398060. If the ICU option is enabled, then it will ignore both any base iconv implementation in libc, as well as any installed iconv port. If the ICU option is disabled, it will ignore any installed icu package, and will (hopefully) use iconv in base if it is present (FreeBSD >= 10), otherwise it will require and use the iconv port. This still needs plenty of testing before I will consider it ready for being committed.
Created attachment 161519 [details] patch to disable use of iconv when the ICU option is disabled The previous patch did not work properly in the case where ICU was disabled, at least on FreeBSD 9.
attachment 161519 [details] works on 10.2. I installed aegisub after building boost-libs with this patch and it works.
Created attachment 161627 [details] patch to allow separate control of icu vs. iconv and force consistent use of iconv The previous patch, which disabled iconv when the ICU option was enabled,(default) caused a regression in science/orthanc. This is the underlying cause of orthanc failing its self-test on FreeBSD 9.3, which does not have iconv in base and boost-libs was not bringing it in as a dependency. Add a separate port option for iconv support. At least one of ICONV or ICU must be enabled. Both are enabled by default. If ICONV is enabled on FreeBSD 9, the port uses the iconv port. If ICONV is enabled on FreeBSD >= 10, the port consistently uses iconv from base and ignores the iconv port if it happens to be installed. The workaround in the previous patch for the ICU_VARS_OFF is no longer necessary since the options framework was fixed in Mk/bsd.options.mk r398258.
A commit references this bug: Author: truckman Date: Thu Oct 1 22:55:27 UTC 2015 New revision: 398395 URL: https://svnweb.freebsd.org/changeset/ports/398395 Log: Add a separate option to allow iconv support to be disabled, but leave it enabled by default to avoid a regression in the science/orthanc unit tests. Set USES=iconv whenever ICONV is enabled, rather than only when ICU is disabled. With the default option settings, this will bring in converters/iconv on FreeBSD 9, which will unbreak the failing unit tests in science/orthanc. At least one of the ICONV or ICU options must be set. Fix PR 198658 in the default case by setting BJAM_ARGS+=-sICONV_PATH=${ICONV_PREFIX} whenever iconv support is enabled, not only when ICU is disabled as was done in r398027 (before that was broken by r398060 and fixed again in the ports framework by r398258). Pet portlint. PR: 198658 Changes: head/devel/boost-libs/Makefile head/devel/boost-libs/pkg-descr