| Summary: | dev-libs/boost-1.52.0-r6 - libs/locale/src/icu/formatter.cpp:61:43: error: call of overloaded 'format(boost::int64_t&, icu::UnicodeString&)' is ambiguous | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Moran Z. <o542018138> |
| Component: | [OLD] Library | Assignee: | C++ Team [disbanded] <cpp+disabled> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | franz.trischberger, gentoo, idarktemplar, o542018138, paolo.pedroni |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=518488 https://bugs.gentoo.org/show_bug.cgi?id=522422 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
dev_libs--boost-1.52.0-r6--build.log
emerge --info |
||
|
Description
Moran Z.
2014-04-16 04:10:14 UTC
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. |
