Bug 185242 – x11-libs/gtk+-2.10.13 self-references installed libraries during build

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Joe Peterson (RETIRED) 2007-07-13 22:26:30 UTC]

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 <[e-mail]>:

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.

[Comment 1 Rémi Cardona (RETIRED) 2008-05-28 08:24:26 UTC]

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. :)

[Comment 2 Gilles Dartiguelongue (RETIRED) 2009-02-28 13:57:13 UTC]

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.

[Comment 3 Pacho Ramos 2010-03-12 11:10:20 UTC]

I am not sure if this is still valid now that we have libtool-2 stable :-/

[Comment 4 Rémi Cardona (RETIRED) 2010-03-13 18:12:08 UTC]

Upstream is using libtool 2 now, let's assume this is fixed. We can always "patch" broken versions by running elibtoolize.

Cheers