Created attachment 375046 [details] dev_libs--boost-1.52.0-r6--build.log Hi There :) I've Been Emerging Some app-office/libreoffice-bin-4.1.4.2 Dependency Packages, But Couldn't Make dev-libs/boost-1.52.0-r6 To Successfully Emerge : The Basic Use Flags For The Above dev-libs/boost Package Are : *** USE="icu mpi nls python threads -debug -doc -static-libs -tools (-context%)" PYTHON_TARGETS="python2_7 python3_2 python3_3 -python2_6" *** & The Resulting Output Is : *** * Package: dev-libs/boost-1.52.0-r6 * Repository: gentoo * Maintainer: cpp@gentoo.org * USE: amd64 elibc_glibc icu kernel_linux mpi nls python python_targets_python2_7 python_targets_python3_2 python_targets_python3_3 threads userland_GNU * FEATURES: preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Unpacking boost_1_52_0.tar.bz2 to /var/tmp/portage/dev-libs/boost-1.52.0-r6/work >>> Source unpacked in /var/tmp/portage/dev-libs/boost-1.52.0-r6/work >>> Preparing source in /var/tmp/portage/dev-libs/boost-1.52.0-r6/work/boost_1_52_0 ... * Applying boost-1.48.0-mpi_python3.patch ... [ ok ] * Applying boost-1.51.0-respect_python-buildid.patch ... [ ok ] * Applying boost-1.51.0-support_dots_in_python-buildid.patch ... [ ok ] * Applying boost-1.48.0-no_strict_aliasing_python2.patch ... [ ok ] * Applying boost-1.48.0-disable_libboost_python3.patch ... [ ok ] * Applying boost-1.48.0-python_linking.patch ... [ ok ] * Applying boost-1.48.0-disable_icu_rpath.patch ... [ ok ] * Applying remove-toolset-1.48.0.patch ... [ ok ] * Applying boost-1.52.0-tuple.patch ... [ ok ] * Applying boost-1.52.0-locale-utf.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/dev-libs/boost-1.52.0-r6/work/boost_1_52_0 ... >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-libs/boost-1.52.0-r6/work/boost_1_52_0 ... * python3_2: running building b2 gentoorelease -j8 -q -d+2 --user-config=/var/tmp/portage/dev-libs/boost-1.52.0-r6/work/boost_1_52_0/user-config.jam -sICU_PATH=/usr pch=off --boost-build=/usr/share /boost-build --prefix="/var/tmp/portage/dev-libs/boost-1.52.0-r6/image/usr" --layout=system threading=multi link=shared --without-context --python-buildid=3.2 Building the Boost C++ Libraries. Performing configuration checks - has_icu builds : yes - iconv (libc) : yes - icu : yes - gcc visibility : yes - long double support : yes Component configuration: - chrono : building - context : not building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building <...> common.copy stage/lib/libboost_wave.so.1.52.0 cp "bin.v2/libs/wave/build/gcc-4.7/gentoorelease/pch-off/threading-multi/libboost_wave.so.1.52.0" "stage/lib/libboost_wave.so.1.52.0" ln-UNIX stage/lib/libboost_wave.so ln -f -s 'libboost_wave.so.1.52.0' 'stage/lib/libboost_wave.so' ...failed updating 1 target... * ERROR: dev-libs/boost-1.52.0-r6::gentoo failed (compile phase): * Building of Boost libraries failed * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 3567: Called python_foreach_impl 'building' * environment, line 3078: Called multibuild_foreach_variant '_python_multibuild_wrapper' 'building' * environment, line 2361: Called _multibuild_run '_python_multibuild_wrapper' 'building' * environment, line 2359: Called _python_multibuild_wrapper 'building' * environment, line 631: Called building * environment, line 3537: Called die * The specific snippet of code: * ejam ${OPTIONS} $(use python && echo --python-buildid=${EPYTHON#python}) || die "Building of Boost libraries failed"; * * If you need support, post the output of `emerge --info '=dev-libs/boost-1.52.0-r6::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-libs/boost-1.52.0-r6::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-libs/boost-1.52.0-r6/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/boost-1.52.0-r6/temp/environment'. * Working directory: '/var/tmp/portage/dev-libs/boost-1.52.0-r6/work/boost_1_52_0' * S: '/var/tmp/portage/dev-libs/boost-1.52.0-r6/work/boost_1_52_0' ~ ~ *** I've Also Tried To Disable The "python" USE-flag - But To No Avail.
Created attachment 375048 [details] emerge --info
you may want to try to apply the patch given here https://bugs.gentoo.org/show_bug.cgi?id=482372 it worked fine for me with glibc-2.18-r1 and boost-1.52.0-r6.
Once I Disable This Package's ICU Support (Via The USE-Flag "-icu") - It Has Proven To Successfully Emerge & Function (Enabling Me To Install & Use LibreOffice), So IMHO This Issue Has Nothing To Do With GLIBC Whatsoever.
Boost 1.52 is quite old. It was released 620 days ago. Boost is on 1.55 right now. In the year and half plus since 1.52, a new ICU release arrived. Perhaps that is the source of the issue. If you unmask the most recent Boost version available in mainline portage, Boost 1.55.0-r1, you will find that it builds correctly with the icu use flag, which is important for anything that needs Boost unicode regex to work correctly (or was the last time I used Boost unicode regex). Are we still on 1.52 for any real reason? There have been some bad bugs in boost::asio fixed since 1.52, in particular one causing failure to detect TCP session closure, if I remember correctly. In other news, I'm having some problems with kernel version 2.2....
We can not migrate on new Boost in stable tree, unless apropriate tracker bugs will be resolved: for 1.53 - https://bugs.gentoo.org/show_bug.cgi?id=boost-1.53 for 1.54 - https://bugs.gentoo.org/show_bug.cgi?id=boost-1.54 There is no tracker bug for 1.55, because when i do whole tinderbox run on it, i did not discover any breakages, that happens with it and NOT happens with 1.54. So, if somebody wants to help us migrate on newer boost - feel free to post patches/fixes on apropriate dependant bugs(not on tracker bugs itself!)
There are some packages that seem to be unmaintained. I left a note where there are newer releases. Other packages already have comments regarding newer versions - without any reaction so far. The only blockers left might be drizzle and sassena. Both have commits since the last (stable) release, so probably they already have fixes in their repos. I will look for fixes when I find the time (hopefully soon) and attach patches.
(Hope it's OK I leave those notes here...) https://bugs.gentoo.org/show_bug.cgi?id=454146 sassena has patches now. Drizzle already had a patch attached, just missed that. So it's up to maintainers now to finally proceed their open bugs. As current stable boost is broken with current stable icu I think finally getting a stable _recent_ boost should have a higher priority than broken (unmaintained?) testing packages.
I have/had the same problem. I stumbled over this: format(boost::int64_t&, icu::UnicodeString&) ^^^^^^^^^^^^^^ Shouldn't this be int64_t soley (without boost namespace)? I ran over the same problem with boost from git. But comment 2 is quit right. This did the trick for me: $ mkdir -p /etc/portage/patches/dev-libs/boost $ cp /usr/portage/dev-libs/boost/files/boost-1.53.0-glibc-2.18-compat.patch /etc/portage/patches/dev-libs/boost/boost-1.53.0-glibc-2.18-compat.patch Thanks to epatch_user this one will be picked up. IMHO the patch boost-1.53.0-glibc-2.18-compat.patch from bug 482372 should be applied to dev-libs/boost-1.52.0-r7 also.
Patch from comment 2 let me successfully build boost. $ LC_ALL=C eix -I boost [I] dev-libs/boost Available versions: 1.52.0-r6(0/1.52) 1.52.0-r7(0/1.52) ~1.53.0-r1(0/1.53) ~1.54.0-r1(0/1.54) ~1.55.0-r1(0/1.55.0)^t {context debug doc icu mpi +nls python static-libs +threads tools PYTHON_TARGETS="python2_7 python3_2 python3_3 python3_4"} Installed versions: 1.52.0-r7(12:16:18 07/30/14)(doc icu mpi nls threads -debug -python -static-libs -tools PYTHON_TARGETS="python2_7 python3_3 -python3_2") Homepage: http://www.boost.org/ Description: Boost Libraries for C++ [I] dev-util/boost-build Available versions: 1.52.0-r1 ~1.53.0 ~1.54.0 ~1.55.0 {examples python test} Installed versions: 1.52.0-r1(13:53:14 09/18/13)(-examples -python -test) Homepage: http://www.boost.org/doc/tools/build/index.html Description: A system for large project software construction, which is simple to use and powerful. Found 2 matches. $ LC_ALL=C eix -I icu [I] dev-libs/icu Available versions: 51.2-r1(0/51.2) 51.2-r2(0/51.2) 52.1(0/52) {debug doc examples static-libs ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"} Installed versions: 52.1(10:54:44 05/26/14)(-debug -doc -examples -static-libs ABI_MIPS="-n32 -n64 -o32" ABI_X86="32 64 -x32") Homepage: http://www.icu-project.org/ Description: International Components for Unicode
Patch from comment 2 worked for me as well.
we are stabilizing -r7, so no reason to fix this for -r6
But boost -v7 suffers from same bug...
I can confirm that this bug still applies to -r7.