Summary: | =media-gfx/hugin-2012.0.0 fails to link with boost-1.53.0 - ../hugin_base/libhuginbase.so.0.0: undefined reference to `boost::thread::{join,start_thread}()' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Erik Zeek <zeekec> |
Component: | Current packages | Assignee: | Gentoo Graphics Project <graphics+disabled> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | bugs, gentryx, rose, saintdev, voyageur |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log. |
Description
Erik Zeek
2013-07-10 20:16:34 UTC
I get the same bug with my own code, but strangely not with a simple "hello world"-like example. Same error here. Is this still an issue in media-gfx/hugin-2013.0.0_rc1 (ebuild in my overlay)? (In reply to Markus Meier from comment #3) > Is this still an issue in media-gfx/hugin-2013.0.0_rc1 (ebuild in my > overlay)? I get the same error. (In reply to Andreas Schäfer from comment #1) > I get the same bug with my own code, but strangely not with a simple "hello > world"-like example. The fact that you see the same error with your own code would indicate that the problem is with boost. I realize that your "hello world" didn't show the problem, but do you have a simple case that does show it? (In reply to Erik Zeek from comment #5) > (In reply to Andreas Schäfer from comment #1) > > I get the same bug with my own code, but strangely not with a simple "hello > > world"-like example. > > The fact that you see the same error with your own code would indicate that > the problem is with boost. I realize that your "hello world" didn't show > the problem, but do you have a simple case that does show it? I don't think this qualifies as simple, but here we go (you'll need the science overlay) emerge -v =dev-libs/boost-1.53.0 emerge -v =libgeodecomp-9999 The last emerge will fail. You can check linking the executable yourself: cd /var/tmp/portage/sci-libs/libgeodecomp-9999/work/libgeodecomp-9999_build/ VERBOSE=true make And yes: it seems to be a Boost issue. (In reply to Markus Meier from comment #3) > Is this still an issue in media-gfx/hugin-2013.0.0_rc1 (ebuild in my > overlay)? Where can I find your overlay? (In reply to Juergen Rose from comment #8) > (In reply to Markus Meier from comment #3) > > Is this still an issue in media-gfx/hugin-2013.0.0_rc1 (ebuild in my > > overlay)? > > Where can I find your overlay? OK, I found http://git.overlays.gentoo.org/gitweb/?p=dev/maekke.git;a=snapshot;h=06c5e9a7143c78571e04aa5b5a2e35ffb920052f;sf=tbz2. With the contained hugin-2013.0.0_rc1.ebuild 'emerge hugin' failed with: cd /var/tmp/portage/media-gfx/hugin-2013.0.0_rc1/work/hugin-2013.0.0_rc1_build/src/tools && /usr/bin/cmake -E cmake_link_script CMakeFiles/autooptimiser.dir/link.txt --verbose=1 /usr/bin/x86_64-pc-linux-gnu-g++ -march=amdfam10 -O2 -pipe -Wl,-O1 -Wl,--as-needed CMakeFiles/autooptimiser.dir/autooptimiser.cpp.o -o autooptimiser -rdynamic ../hugin_base/libhuginbase.so.0.0 -lboost_thread-mt -lboost_date_time-mt -lboost_regex-mt -lboost_filesystem-mt -lboost_iostreams-mt -lboost_system-mt -lboost_signals-mt -lpano13 -latllapack -lf77blas -latlcblas -lGLEW ../foreign/levmar/libhuginlevmar.a ../foreign/vigra/vigra_impex/libhuginvigraimpex.so.0.0 -lImath -lIlmImf -lIex -lHalf -lIlmThread -ljpeg -ltiff -lpng -lz -lz -lexiv2 -lpthread -lImath -lIlmImf -lIex -lHalf -lIlmThread -ljpeg -lpng -lz ../hugin_base/makefilelib/libmakefilelib.so.0.0 -lpthread -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXmu -lXi -lpthread -lGLU -lGL -lSM -lICE -lX11 -lXext -lglut -lXmu -lXi -lboost_thread-mt -lboost_date_time-mt -lboost_regex-mt -lboost_filesystem-mt -lboost_iostreams-mt -lboost_system-mt -lboost_signals-mt -lpano13 -latllapack -lf77blas -latlcblas -lGLEW -ltiff -lexiv2 -llensfun -Wl,-rpath,/var/tmp/portage/media-gfx/hugin-2013.0.0_rc1/work/hugin-2013.0.0_rc1_build/src/hugin_base:/var/tmp/portage/media-gfx/hugin-2013.0.0_rc1/work/hugin-2013.0.0_rc1_build/src/foreign/vigra/vigra_impex:/var/tmp/portage/media-gfx/hugin-2013.0.0_rc1/work/hugin-2013.0.0_rc1_build/src/hugin_base/makefilelib: ../hugin_base/libhuginbase.so.0.0: undefined reference to `boost::thread::join()' ../hugin_base/libhuginbase.so.0.0: undefined reference to `boost::thread::start_thread()' collect2: error: ld returned 1 exit status make[2]: *** [src/tools/autooptimiser] Error 1 (In reply to Andreas Schäfer from comment #6) > I don't think this qualifies as simple, but here we go (you'll need the > science overlay) > > emerge -v =dev-libs/boost-1.53.0 > emerge -v =libgeodecomp-9999 > > The last emerge will fail. You can check linking the executable yourself: > > cd /var/tmp/portage/sci-libs/libgeodecomp-9999/work/libgeodecomp-9999_build/ > VERBOSE=true make Sorry for not getting back to this sooner, but libgeodecomp emerges just fine for me. I found it! For some reason, I had two directories from older installs of boost hanging around (/usr/include/boost-1_5{1,2}). Hugin was picking up the 1.52 version of the headers (you can see it in the build log), and then linking against 1.53 version of the libs. Neither of those old directories were claimed by any packages. They are probably left over from when slotting boost was dropped. Jikes, I too had old Boost leftovers on my disk. Removing those fixed compilation with Boost 1.53 for me. And I thought I had already pruned them. Thanks, Erik! (In reply to Erik Zeek from comment #11) > I found it! > > For some reason, I had two directories from older installs of boost hanging > around (/usr/include/boost-1_5{1,2}). Hugin was picking up the 1.52 version > of the headers (you can see it in the build log), and then linking against > 1.53 version of the libs. > > Neither of those old directories were claimed by any packages. They are > probably left over from when slotting boost was dropped. This fixed it for me too. Thanks for finding that Eric! Thanks Eric, I found a /usr/include/boost-1_51 directory. After removing this directory I could emerge hugin-2013.0.0_rc1. Thank you Erik! *** Bug 480488 has been marked as a duplicate of this bug. *** |