I'm the maintainer of the Debian libtool package, and someone
just pointed me to:
This seems to be a very old entry, so I don't know if people see
I think the relevant Debian bug for this is:
The problem discussed in that bug in short:
Debian has a patch to reduce the number of DT_NEEDED entries
in binaries and libraries to only those that should be needed.
This is done by reducing the number -l's that libtool passes to
the linker. The patch has some side effects.
One of the effects is that if you have 2 versions of a library,
one in the standard search path, and one somewhere else, the
linker could pick up the wrong one. This might result in
problems if those 2 libraries aren't compatible.
In case of libtool without this patch, libtool might call the
linker with the non-installed version and result in finding all
symbols it needs. While on the other hand, libtool with Debian's
patch would follow the DT_NEEDED and find the other library.
So this is a problem in case you have 2 versions of a library,
and they're not compatible. In case that you link indirectly to
that library, with Debian's version, the linker might find the
other version, and fail to link.
In this case it would probably be 2 incompatible libapr-0.so.0,
on installed in /usr/lib, the other in the source dir.
The weird part about this is that it's about symbols that aren't
from libapr-0.so.0 that the linker is complaining about. It
looks to me like libaprutil-0.so should have linked against some
libdb version but didn't. It's also saying to link to libapr on
the command line, so I don't think this has anything to do with
libtool. Maybe I'm looking at the wrong bug report?
Do you have something else I can take a look at?
Anyway, I hope this clears up some things. Feel free to ask more
questions if you have any.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Feb 21 13:23:38 2006