boost checks for the presence of the _GLIBCXX_HAVE_GTHR_DEFAULT macro in order to determine if threading support is available in libstdc++. In GCC 4.7 the macro has been renamed _GLIBCXX_HAS_GTHREADS. This causes BOOST_DISABLE_THREADS to be exported which causes the build to fail. gcc.compile.c++ bin.v2/libs/thread/build/gcc-4.7/gentoorelease/pch-off/threading-multi/pthread/once.o "x86_64-pc-linux-gnu-g++" -ftemplate-depth-128 -O2 -march=native -g -pipe -D_FORTIFY_SOURCE=2 -finline-functions -Wno-inline -Wall -pthread -fPIC -Wno-long-long -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DNDEBUG -I"." -c -o "bin.v2/libs/thread/build/gcc-4.7/gentoorelease/pch-off/threading-multi/pthread/once.o" "libs/thread/src/pthread/once.cpp" In file included from ./boost/thread/detail/platform.hpp:17:0, from ./boost/thread/once.hpp:12, from libs/thread/src/pthread/once.cpp:7: ./boost/config/requires_threads.hpp:29:4: error: #error "Threading support unavaliable: it has been explicitly disabled with BOOST_DISABLE_THREADS" This has been fixed upstream: https://svn.boost.org/trac/boost/ticket/6165 https://svn.boost.org/trac/boost/changeset/76133
Created attachment 304895 [details] build.log
The fix is included in dev-libs/boost-1.49.0.
This has been fixed in 1.49 and I have no interest in backporting this to 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing.
Leave porting bugs open until the fix is available please. I need to keep track of what remains to be done.
Done.
*** Bug 418049 has been marked as a duplicate of this bug. ***
Please leave these bugs open to avoid duplicates (like I did) and give people with standard bugzie setups (w/o ALL on every query) a chance to discover them. This subject is not resolved/fixed. Just reso/wont-backport ...
Either way it won't show up, and we're not leaving it open indefinitely. Just check the tracker for dups before you file. That's what it's for.
*** Bug 424319 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > This has been fixed in 1.49 and I have no interest in backporting this to > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. And what about packages that depends of boost 1.48 ? Like grive.
(In reply to comment #10) > (In reply to comment #3) > > This has been fixed in 1.49 and I have no interest in backporting this to > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > And what about packages that depends of boost 1.48 ? Like grive. Don't reply on closed bugs because there is a chance we never see them. Poke grive upstream to support a newer boost.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #3) > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > And what about packages that depends of boost 1.48 ? Like grive. > > Don't reply on closed bugs because there is a chance we never see them. Poke > grive upstream to support a newer boost. Sorry this bug was not closed
How many packages do exclusively depend on <=boost-1.48 ? And: have you openened a bug report for grive ? I just tested grive with boost-1.49-r1 and GCC-4.7.1. No problems here.
I just created Bug 426848 for grive.
*** Bug 429634 has been marked as a duplicate of this bug. ***
Created attachment 320180 [details, diff] make gcc-4.7 happy compile (In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > (In reply to comment #3) > > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > > > And what about packages that depends of boost 1.48 ? Like grive. > > > > Don't reply on closed bugs because there is a chance we never see them. Poke > > grive upstream to support a newer boost. > > Sorry this bug was not closed hi, markos, I would be appreciate if you can apply this trival patch which Ryan hill already point out. It's really simple, which won't bring any side effect . I've tested with gcc-4.7.1, it works fine. attached file is the patch, add one line epatch to ebuild also,It would be fine if you still insist keep this bug open, I could put it into my overlay...
(In reply to comment #16) > Created attachment 320180 [details, diff] [details, diff] > make gcc-4.7 happy compile > > (In reply to comment #12) > > (In reply to comment #11) > > > (In reply to comment #10) > > > > (In reply to comment #3) > > > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > > > > > And what about packages that depends of boost 1.48 ? Like grive. > > > > > > Don't reply on closed bugs because there is a chance we never see them. Poke > > > grive upstream to support a newer boost. > > > > Sorry this bug was not closed > > hi, markos, I would be appreciate if you can apply this trival patch which > Ryan hill already point out. It's really simple, which won't bring any side > effect . > I've tested with gcc-4.7.1, it works fine. > attached file is the patch, add one line epatch to ebuild > > also,It would be fine if you still insist keep this bug open, I could put it > into my overlay... I don't mind backporting this to boost-1.48 but is there a reason to fix this version? As far as I can tell, ~testing users should just migrate to 1.49.0 asap.
(In reply to comment #17) > (In reply to comment #16) > > Created attachment 320180 [details, diff] [details, diff] [details, diff] > > make gcc-4.7 happy compile > > > > (In reply to comment #12) > > > (In reply to comment #11) > > > > (In reply to comment #10) > > > > > (In reply to comment #3) > > > > > > This has been fixed in 1.49 and I have no interest in backporting this to > > > > > > 1.48. By the time gcc-4.7 hits portage, 1.49 will be in ~testing. > > > > > > > > > > And what about packages that depends of boost 1.48 ? Like grive. > > > > > > > > Don't reply on closed bugs because there is a chance we never see them. Poke > > > > grive upstream to support a newer boost. > > > > > > Sorry this bug was not closed > > > > hi, markos, I would be appreciate if you can apply this trival patch which > > Ryan hill already point out. It's really simple, which won't bring any side > > effect . > > I've tested with gcc-4.7.1, it works fine. > > attached file is the patch, add one line epatch to ebuild > > > > also,It would be fine if you still insist keep this bug open, I could put it > > into my overlay... > > I don't mind backporting this to boost-1.48 but is there a reason to fix > this version? As far as I can tell, ~testing users should just migrate to > 1.49.0 asap. hi markos, as My suggestion, it's better to have... 1) since it still in tree, if you think it useless why not remove it? :-) 2) another reason, package such as libreoffice depends on boost, migrate to 1.49 will cause it re-compile (emerge @preserved-rebuild), it really takes huge time... which may not as the intention of user, so base my own personal experience I'd like to keep boost multi version/slot installed, and emerge libreoffice at *proper* time
For slotted packages I think we should fix the latest version in each slot*. There's not much point in having them in the tree if you can't build them. *(within reason of course - I don't expect it to be backported all the way back to 1.35, though I wonder why we still have those versions)
Ok, patch applied. Do we still need to keep this bug open?
Nah, good to go.
