Lately I have experienced several situations where an ebuild failed because some part of the build process linked against an already installed older version of some library (e.g. in /usr/lib) instead of the version just built by the same ebuild (which is somewhere in the current work dir of the ebuild). A workaround to problems of this kind is to first unmerge the old version so the installed version of the library no longer exists. After that, emerging the new version works. I guess some bug to collect problems of this kind might be useful, so a general solution applying to all these cases can be found. I leave it to some more "official" party (i.e. some gentoo dev) to decide if other bugs should be linked to this as DUPs of this one (discourages individual solution), as Depending on this one (which probably makes the most sense) or as Blocking this one (as is done with Tracker bugs). Bugs that I know of that experience this problem: bug #121142 for media-gfx/imagemagick bug #131407 for sci-misc/kboincspy bug #119776 comment #20 suggests it for sci-misc/boinc
bug #131214 is the same with appoffice/koffice-libs.
Similar error with kivio-1.5.0: .libs/straight_connector.o:(.gnu.linkonce.d._ZTV22KivioStraightConnector+0x170): undefined reference to `Kivio1DStencil::setCustomIDPoint(int, KoPoint const&, KivioPage*)' .libs/straight_connector.o:(.gnu.linkonce.d._ZTV22KivioStraightConnector+0x174): undefined reference to `Kivio1DStencil::customIDPoint(int)' collect2: ld returned 1 exit status libtool: install: error: relink `straight_connector.la' with the above command before installing it make[4]: *** [install-kde_moduleLTLIBRARIES] Error 1 make[4]: Leaving directory `/var/tmp/portage/kivio-1.5.0/work/kivio-1.5.0/kivio/plugins/kivioconnectortool/straight_connector' And another with app-office/karbon-1.5.0, with several screen pages of unresolved references, I won't paste all of that here.
Please, use this as a tracker *only* - i.e., file *separate* bugs for each ebuild and make the bug block this one, if you wish to have a tracker. Making it a dumpspace for error logs is useless and won't make the issues fixed. Thanks.
Would it be feasible to use sandbox to hide the existece of the installed version of a library from the same package from the linker? Idea: 1. Find all files that are part of this package (like qlist does) and store them in some environment variable. 2. Apply a check in sandbox whenever a file is tested for existence or opened for reading. 3. If the file is listed in the environment variable, behave as if it did not exist.
Except for bug #121142, all those bugs so far are related to some part of KDE, and the error always occurs in some install-recursive call to make, when libtool --mode=install executes relink_command. I don't know enough about libtool to understand why relinking is required during the installation phase and cannot be done in the compile phase. Maybe it is possible to tweak the relink_command entries of the *.la files, or tweak the libtool script itself, to make things work.
(In reply to comment #4) > Would it be feasible to use sandbox to hide the existece of the installed > version of a library from the same package from the linker? Uh, that's a nasty hack... better fix the apps.
One bug suffices. *** This bug has been marked as a duplicate of 131523 ***
