/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../liborigin2.so: undefined reference to `boost::thread_resource_error::thread_resource_error()' collect2: ld returned 1 exit status make[1]: *** [qtiplot] Error 1 make[1]: Leaving directory `/var/tmp/portage/sci-visualization/qtiplot-0.9.7.11-r2/work/qtiplot-0.9.7.11/qtiplot' ebuild fails to link due to undefined reference to boost::thread_resource_error. I think the issue is that liborigin2 depends on libboost_thread i.e. -lboost_thread-mt should appear *before* -lorigin2 Reproducible: Always Steps to Reproduce: 1. emerge qtiplot 2. 3. Actual Results: thonScripting.o ../tmp/qtiplot/qrc_icons.o -L/usr/X11R6/lib -L/usr/lib/qt4 -lmuparser ../3rdparty/qwt/lib/libqwt.a -lgsl -lgslcblas -lboost_date_time-mt -lboost_thread-mt -lorigin2 -lpython2.6 -lm -lQTeXEngine -lgl2ps -lQtAssistantClient -lGLU -lGL -lQtSvg -L/usr/lib/qt4 -L/usr/X11R6/lib -lQt3Support -lQtSql -L/usr/lib/mysql -lQtXml -lQtOpenGL -lQtGui -lQtNetwork -lQtCore -lgthread-2.0 -lrt -lglib-2.0 -lpthread /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../liborigin2.so: undefined reference to `boost::thread_resource_error::thread_resource_error()' collect2: ld returned 1 exit status make[1]: *** [qtiplot] Error 1
@reporter: Make sure liborigin and qtiplot use the same boost version (recompiling liborigin should help). @maintainer: Make sure the ebuild uses the versioned include and lib directories. Have a look at dev-python/visual-5.13 for how to do it. The same applies for liborigin.
Indeed, recompiling liborigin fixes the problem. Thanks !
(In reply to comment #1) > @maintainer: Make sure the ebuild uses the versioned include and lib > directories. Have a look at dev-python/visual-5.13 for how to do it. The same > applies for liborigin. @boost: Could you tell me what's the reason to have eselectable boost in case we'll force our package to use most recent version in any case? Also such things should be documented somewhere (probably in to be written boost.eclass).
> @boost: Could you tell me what's the reason to have eselectable boost in case > we'll force our package to use most recent version in any case? Also such > things should be documented somewhere (probably in to be written boost.eclass). > eselect-boost is to ease life of people that use boost for their own projects/work. Packages should dep on most recent installed versions disregarding anything eselected.
(In reply to comment #4) > eselect-boost is to ease life of people that use boost for their own > projects/work. Packages should dep on most recent installed versions > disregarding anything eselected. Besides for people who work with boost, is there any use for slotted boost? Since problems like reported here are not evident (fortunately it failed to build, but what happens if it succeeds?) and since there are no ready to use tools (or do we have something like python-updater for boost?) to rebuild packages after boost upgrade looks like this slots just create a number the problems to solve only one. And even if this feature is really wanted, probably another multislot hack can be introduced... That said, given the number of ebuilds that depend on boost some common solution required (eclass to give us correct include/library path with some documentation). Also currently most ebuilds in the tree depending on boost do things like qtiplot does, so if what you speak here is really wanted this should be announced on -dev and bugs filled... Until that happens I doubt I'm going to take such changes in ebuild since most probably as soon as people realize consequences of slotting boost will be unslotted and I'll have to get this changes back.
(In reply to comment #5) > Besides for people who work with boost, is there any use for slotted boost? > Since problems like reported here are not evident (fortunately it failed to > build, but what happens if it succeeds?) and since there are no ready to use > tools (or do we have something like python-updater for boost?) to rebuild > packages after boost upgrade looks like this slots just create a number the > problems to solve only one. And even if this feature is really wanted, probably > another multislot hack can be introduced... > The gain is to come with EAPI 3 slot operator dependencies (or EAPI 3.14, or EAPI 4, I've lost track on where is which feature) -- packages will be able to explicitly depend upon highest installed boost version at the time of their install. That will actually make tools like python-updater not need: package manager will bail off if a user were to uninstall boost slot that some package linked against. Before boost was slotted each and every such package would have to be rebuild as upstream doesn't care about ABI compatibility at all. Having said that, the big problem we're facing here, that was discovered after slotting, are packages that depend upon boost *and* upon packages that depend upon boost. Version mismatch there produces behaviours from link errors to segfaults and I don't know of any real good solution to that.
(In reply to comment #6) > Having said that, the big problem we're facing here, that was discovered after > slotting, are packages that depend upon boost *and* upon packages that depend > upon boost. Version mismatch there produces behaviours from link errors to > segfaults and I don't know of any real good solution to that. Heh, very same reasons lead to de-slotting of mysql so this is kind of known problem for Gentoo. And that is why I'm against any modifications of the way qtiplot builds since it will worth only after required infrastructure is in place. And by infrastructure I mean at very least some tool to rebuild elf-dependent packages against single boost slot (of course ideally some portage patch). But getting back to eclass. Have you considered eclass which will be inherited by all packages that depend on boost and will record boost SLOT against which package was build? I haven't thought hard on this but this may allow to keep track of used boost SLOTs and write boost-updater tool which will rebuild all packages against same boost version (even possible to rebuild only for cases you've mentioned but not all apps). Well, again I'm not sure if this maintaining burden worth few developers that need different boost versions installed in parallel and probably de-slotting is best solution here.
(In reply to comment #1) > @maintainer: Make sure the ebuild uses the versioned include and lib > directories. Have a look at dev-python/visual-5.13 for how to do it. This is functionality that should abstracted to an eclass.
And indeed we de-slotted it.
