Bug 198658 - devel/boost-libs: libboost_locale.so fails to link libiconv if installed
Summary: devel/boost-libs: libboost_locale.so fails to link libiconv if installed
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Don Lewis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-17 14:45 UTC by Philip Homburg
Modified: 2015-10-02 00:03 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (office)


Attachments
patch to disable use of iconv when the ICU option is disabled (886 bytes, patch)
2015-09-29 01:50 UTC, Don Lewis
no flags Details | Diff
patch to disable use of iconv when the ICU option is disabled (1.49 KB, patch)
2015-09-29 08:41 UTC, Don Lewis
no flags Details | Diff
patch to allow separate control of icu vs. iconv and force consistent use of iconv (1.55 KB, patch)
2015-10-01 22:06 UTC, Don Lewis
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Homburg 2015-03-17 14:45:17 UTC
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.
Comment 1 mvharding 2015-05-21 15:11:02 UTC
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.
Comment 2 mvharding 2015-05-26 16:44:19 UTC
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.
Comment 3 mvharding 2015-05-26 18:08:50 UTC
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...
Comment 4 Don Lewis freebsd_committer freebsd_triage 2015-09-27 08:37:24 UTC
Can you try boost-libs r398027?
Comment 5 Philip Homburg 2015-09-28 19:54:47 UTC
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
Comment 6 Don Lewis freebsd_committer freebsd_triage 2015-09-28 21:06:56 UTC
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.
Comment 7 Philip Homburg 2015-09-28 21:41:01 UTC
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.
Comment 8 Don Lewis freebsd_committer freebsd_triage 2015-09-29 01:44:43 UTC
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.
Comment 9 Don Lewis freebsd_committer freebsd_triage 2015-09-29 01:50:57 UTC
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.
Comment 10 Don Lewis freebsd_committer freebsd_triage 2015-09-29 08:41:52 UTC
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.
Comment 11 Philip Homburg 2015-09-29 10:09:45 UTC
attachment 161519 [details] works on 10.2. I installed aegisub after building boost-libs with this patch and it works.
Comment 12 Don Lewis freebsd_committer freebsd_triage 2015-10-01 22:06:16 UTC
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.
Comment 13 commit-hook freebsd_committer freebsd_triage 2015-10-01 22:56:11 UTC
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