Public SourceMage Discussion List

[Remko van der Vossen <wich AT yuugen.jp>]

On Wed, Nov 11, 2009 at 09:53:29PM -0600, Javier Vasquez wrote:
> It's still not clear to me what needs to be recompiled though...  See
> I can't easily identify spells providing them.  Any ways, I'm not sure
> if it's the libraries, or the "lt-gtk-query-immodules-2.0" itself, in
> which case it's kind of the same gtk+2 which is failing, isn't it?
> 
> Could you please provide guidance?  So far my work around was to add
> the links I mentioned, which seems to work OK, :-)
> 
> Also librsvg2 fails, but not to compile, it fails to install, because:
> 
> gdk-pixbuf-query-loaders > "$INSTALL_ROOT/etc/gtk-2.0/gdk-pixbuf.loaders"
> 
> Which is inside FINAL, fails due to the same library...
> 
> BTW, I guess there are other things to recompile besides gtk+2, since
> several things don't work without the links such as midori, pidgin,
> etc...  In such cases, all the links I mentioned were missing...
> 
> I'm attaching the gtk+2 log for the failed attempt...

Don't really have the time to plow through it right now.

Let me first explain a bit about what .la files are and what they do.
Libtool installs the .la files along with libraries to assist the linker
in determining the full dependency tree when linking in a library.

Let's assume the following scenario: We have a lib_a that depends on
lib_b and a prog_a that depends on lib_a. That means that for prog_a to
work, the binary images of prog_a, lib_a as well as lib_b have to be
loaded in memory. In the case of a static build that means linking in
prog_a.o, lib_a.a and lib_b.a, but of course prog_a should not need to
know about lib_a depending on lib_b. This is what libtool can be used
for, libtool can give the full list of objects that need to be linked in
when requesting a certain library. Libtool retrieves this information
from its own .la files which are generated when using libtool to build
libraries. The .la files are text files containing metadata on the
library, including dependency information.

Of course these days, the largest part of our system is dynamically
linked. In a dynamically linked binary the dependency metadata is
included in the executable, the binary image of prog_a includes the list
of all dynamic objects which need to be loaded alongside the binary
image of the program itself. So in this case the linker will, instead of
linking in the static libraries, add all necessary libraries to the list
of needed objects in the program binary. Again libtool can be used to
determine this list of needed libraries.

In the early days of dynamic linking the executable needed to have a
full list of all dependencies, including the indirect dependencies.
These days however that is not necessary anymore. The dyanmic loader
will also examine the metadata of the libraries it loads and load any
dependencies recursively. Unfortunately libtool still works on the old
model of generating a full list of dependencies, so even if the dynamic
object of lib_a already contains the dependency metadata to load lib_b,
when using libtool lib_b will still be included as a dependency of
prog_a, even though it is not directly used.

Anyway, if it is indeed the .la files that are the problem they are easy
to find and determine which spells you need to recast:

find /usr/lib -name '*.la' -print0 | xargs -0 grep -l $lib-1.3.so |
xargs gaze from | cut -d: -f1 | sed 's/\(.*\)-[^-]*/\1/' | sort -u 

Where $lib is replaced with each of the offending libs.

Disclaimer: I haven't actually tested the above, but I think it should
work, the idea is to find all libtool .la files, determine which ones
have references to the offending libs and finally find the spells that
installed those la files. Also this only checks /usr/lib, you might also
want to check /lib.

Once that's done you will have updated all libraries that depend on the
updated directfb libraries and will have updated .la files. Now you
probably want to do a cleanse --fix, to check for any libs and programs
that got indirectly linked to the old *-1.3.so files due to these la
files.

Regards,

Remko van der Vossen.