Re: libtool problem
On 25 Feb 1999, Brian Warner wrote:
> Is the bugreport from a non-i386 platform, by any chance? I'm running on a
My system is an i386 (don't know anything about the bug-reporter.
It doesn't work for me.
> 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.
configure and make work without any problem, but libgtkdatabox.la has
the following entrys:
# Names of this library.
library_names='libgtkdatabox-0.1.7.so.6.0.0 libgtkdatabox-0.1.7.so.6 libgtkdatabox.so'
# The name of the static archive.
old_library='libgtkdatabox.a'
# Libraries that this one depends upon.
dependency_libs=''
^^^^^^^^^^^^^^^^^^
This is for sure the core of the problem. I compared the file
libgtkimreg.la (I maintain both libgtkimreg and libgtkdatabox) which
is relatively similar (but the configure stuff was written by me :-) ),
and the dependency_libs field contains a lot of reasonable information.
Thus the problem seems to have its source in the configure.in file
or any other libtool influencing file.
> (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 problem is, that it occures on *all* systems including the system of
the upstream author and he didn't know any clue.
> 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 is exactly the line in the ltconfig file of the upstream author.
By the way, he told me that I got his configure stuff by cut-n-pasting
the GTK things ...
> 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.
So this doesn't seem to be the reason for the problem.
Thanks anyway
Andreas.
Reply to: