[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libtool problem

Is the bugreport from a non-i386 platform, by any chance? I'm running on a
powerpc and have noticed many versions of libtool which use a rather
i386-centric regexp to identify shared libraries. The expression expects
file(1) to report 'ELF 32-bit LSB shared object' when run on a .so
file. Big-endian or 64-bit machines won't match, so libtool thinks that your
(depended-upon) libraries are static instead of shared. Then you get warnings
while building the libraries about "I can record information about library
dependencies for -lfoo in the resulting library file if you have shared
libraries, which you don't", and thus no dependency information is recorded.

(libtool is creating a little shell script called libfoo.la that is intended
to be parsed by another libtool, the one in the application being linked
against -lfoo . Part of that script tells the second libtool to include other
libraries when linking [a good example is imlib, whenever you link against
-limlib you also need -lgif -lXpm -ltiff etc]. The actual .a/.so file doesn't
necessarily contain the dependency information, but if you were to compare the
installed .la file on your system against the bug reporter's system, you'd
probably see a difference).

The fix I've seen is to patch ltconfig before running ./configure (which
builds libtool). Look for a line with the string "ELF 32-bit LSB" and make it
look more like this (taken from gtk+-1.1.16):

  check_shared_deplibs_method='file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )'

This has been showing up more and more as libtool becomes popular, especially
in gnome libraries since they all tend to depend upon one another (imlib is
the worst). I don't know if there is a newer libtool that fixes this, but if
so, asking the author to rebuild their distribution with a newer ltconfig
would remove the need for a local patch.


tille@physik.uni-halle.de (Andreas Tille) writes:
> Hello,
> I'm the maintainer of the libgtkdatabox package.  I've got a bugreport
> about missing dependencies.
> > Date: Thu, 25 Feb 1999 17:36:27 +0900
> > From: Ionutz Borcoman <borco@borco-ei.eng.hokudai.ac.jp>
> > Subject: Bug#33841: libgtkdatabox: missing dependencies
> > 
> > Package: libgtkdatabox
> > Version:
> > 
> > libgtkdatabox is not depending of anything else except libc6, while it
> > needs gtk to run.
> Because I really don't know why this happens I checked
> /usr/lib> ldd libgtkdatabox-0.1.7.so.6.0.0
>         libc.so.6 => /lib/libc.so.6 (0x4000a000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)
> and so the reason for the dependency problem is caused by the
> linking of library.  I asked the upstream author if he has any clue
> but he doesn't (it the same strange result at his box).
> The library works well as you can check with the example program.
> I expect problems in the libtool mechanism which the author has changed
> but I'm really no libtool expert and I would like to ask if someone
> who knows more about libtool could check the problem.

Reply to: