I've seen this twice now, so I guess it must be a bug in the ebuild system When a package has a library that gets upgraded to a new so-name, the binary gets linked to the old name, not the new one being created in the ebuild. Example, when gimp was upgraded to 1.3.14, libgimpbase went from .so.13 to .so.14. The linker linked to the old version in /usr/lib, so when emerge finished by unmerging the old version, the gimp binary had an unresolved link to .so.13. emerging again worked, since there now was only one version of libgimpcore on the system This error is only seen when a library actually changes so-name, since if it doesn't, ld.so will resolve the link to the new lib Reproducible: Always Steps to Reproduce: 1. 2. 3.
*** Bug 19659 has been marked as a duplicate of this bug. ***
My question pertains to the impact on gimp? If I manually link it to the old binary so that it starts will gimp loose all semblance it once had to stability or is this an acceptable low risk work around for now?
oops, I meant old *library* not binary :S my bad..
so-names generally get changed for a reason. Binary incompatibility is the usual reason. If you install the old lib it would almost certainly fail with unresolved symbols All you need to do to get gimp running is to run "emerge gimp" again, that's the quick fix for that particular package. This bug report is for ebuild to get fixed, so that won't be necessary in future
The weird thing is that If I made the link to the old lib then gimp would start and run and spit out a few warnings, as opposed to just rolling over and playing dead.. so I wasnt sure at the time if the warnings were so-name related or just gimp centric since it is a development release. But I did re-emerged gimp, and it works without the link now. Thanks.
reporter, when did you see this before ? what version of binutils are you guys running exactly ? It seems to be some double linking problem, but i'm not sure if its the Gimp itsself that is to blame.
I saw it before in gtkhtml. It's not a very common error, since most libs don't change so-name that often. binutils is 2.13.90.0.20-r1
This is the first time Ive seen this error. Im running binutils-2.13.90.0.20-r1
#7 how do you mean 'change so name' ?
Well, how should I put it? You know what an so-name is? Try "objdump -p /usr/lib/libgimpbase-1.3.so.14|grep SONAME". That's the name the binary gets linked to. When ld.so, the dynamic linker, searches for a library it only looks at the so-name. Most libs when they go to a new version they keep the same so-name, to preserve compatibility. Similarly, when they change so-name, they usually change the whole file name too, so the two versions can live together, look at libgtk-1.2 => libgtk-x11-2.0 for example. The problem here (I think) is that when the ebuild compiles, it tells the linker to search the standard system directories before the current work directory. So when gimp gets compiled with -lgimpbase, it finds the old one, with the old so-name.
yes i know all that, but libgimpbase doesn't change name (?) it is in both version, that is what confuses me about your statement. And why would it link only libgimpbase wrong, there are other gimp so's around.
libgimpbase-1.3 changed soname. In gimp-1.3.13, the soname was libgimpbase-1.3.so.13, and in gimp-1.3.14 it is libgimpbase-1.3.so.14. As far as I could see, the other libs didn't change soname.
they all change so name, all libs now have .14
OK, good point, I didn't look at the others to be honest. Maybe they were mislinked too, maybe there's something special about libgimpbase that causes it to be mislinked, I don't know. I'm reemering 1.3.13 now to look a bit more carefully
OK, you're right. The other libs were correctly linked. I guess that means it's not a general problem, but a bug somewhere in the gimp makefile
azarah, would you have a look at this. Note that the latest libgtkhtml-3.0.2 shows the same sort of problem when upgrading from 3.0.1 . I think it might be some libtool problem, but i have no idea where to start looking.
Known issue. Problem is that libtool get the order of lib search dirs wrong, and then link to the lib in /usr/lib. Fix should be simple ... inherit the 'libtool' eclass, and then add to src_{unpack,compile}(): elibtoolize --reverse-deps If there are issues, maybe just rip the patch out, although I would rather want to know what the issues are if there are.
i think liquidx did that for this package, but not completely sure. i'll poke him about it.
turns out we already tried that. It all of a sudden appeared in two unrelated packages and i talked to the Gimp guys and they say the changed nothing in the build system lately, i suspect some other component must have to do with it.
Did they maybe update the version libtool they are using ? Did liquidx remove those changes again, as I do not see them in the build ?
no we tested that locally, not much use in changing the ebuild if it doesn't work.
happens when upgrading from 1.3.14 to 1.3.15. Also the gnome menu entry isn't available.
raker, since you bumped it, maybe you have the time to figure out and fix the issue as well.
i've just committed 1.3.16. i've added the elibtoolize patch which seems to work with this version to solve the upgrade problem. can someone verify it works now?
hmm .. i've had no complaints so far .. i'll assume it is fixed.
