Basically, some part of the gtk+ build references the *installed* /usr/lib/libgdk_pixbuf-2.0.so library during the build process. A package build should not depend on something that was installed from a previous version of the same package. This was discovered due to the fact that the installed version referenced the wrong library, so the build failed. Only *unmerging* and re-merging worked. It is hard to reproduce unless this condition exists, which is unusual. Here is my fuller description: libgmodule only became a clue trail in this. You see, it looks like a previous install of glib on my system had strange numbering (i.e. ".so.1200" suffix rather than "so.0") due to lack of elibtoolize in the ebuild - this according to the g/fbsd folks. Because of this, I can tell what packages/files were built against the *old* glib (gtk+ being one of them). Now the issue somes when tryng to "fix" gtk+. Like most packages, it should just rebuild and now link against the ".so.0" glib libs, but this did not work. It looks like the /usr/lib/libgdk_pixbuf (installed version) was either being linked against or being used in some way. The clue is the error about libgmodule..so.1200 from libgdk_pixbuf. In other words, if it were using a freshly built libgdk_pixbuf, it would not have complained about the glib lib. So bottom line is that gtk+ seemed to be relying on it's own libgdk_pixbuf, but it was using an old installed version of this. Note that unmerging gtk+ and then rebuilding got around the issue, which is another clue that it was looking at what was *installed* rather than its own build stuff. It seems that packages should always succeed in rebuilding (in the sandbox), regardless of whether they are already installed or not. The only reason a fatal error happened is due to the glib mismatch... does this make sense? This is a bit hard to reproduce now, since I'd have to somehow cause libgdk_pixbuf (the installed lib) to throw a link error and try the build again. I can try this in order to get a build log if that's helpful... And a respose from <remi@gentoo.org>: Yeah, vlc had(still has?) this issue too. Somewhere in some random Makefile.am you would find a -l/usr/lib before the local $(builddir). So, vlc would link with a previous installation of itself. This may not be very hard to fix, to it's going to be a b*tch to find the place where the error is actually made.
Actually, I was thinking (yes, it happens!) : could we use sandbox to find that sort of things? A couple of weeks ago, I had a similar bug with anjuta with make -jN. Due to b0rked makefiles, anjuta would link against the installed copy thus hiding the parallel make bug. Anyway, the only way for us all to fix anything is to first *find* what's happening. :)
as we figured in some other packages (evolution), it might also just be a libtool-1 related bug. Unless you can spot an obvious error in the Makefile.ams.
I am not sure if this is still valid now that we have libtool-2 stable :-/
Upstream is using libtool 2 now, let's assume this is fixed. We can always "patch" broken versions by running elibtoolize. Cheers
