On Sat, 2005-01-22 at 01:01 +0000, Philip Martin wrote: > Sorry this is so long, a quick summary: Debian's libtool appears to resolve > inter-library dependencies to the install tree rather than the build tree, > this is different from the upstream GNU behaviour and can be awkward for > people using Debian as a development platform. > I think I know what's causing this, can you just confirm something for me though.
> This mentions libsvn_ra-1.so but doesn't mention the three dependent > libraries, however the link normally succeeds whether or not I have > libraries installed in $HOME/subversion/lib. > This is correct behaviour for Linux. The Linux dynamic link loader can traverse the dependencies of shared libraries and load their dependencies in automatically. There is no need to link the entire dependency tree to the binary, just the immediate dependencies. > A recent change to the Subversion source (revision 12801) introduced > new functions into the three dependent libraries, and made > libsvn_ra-1.so reference those new functions. > Does only libsvn_ra-1.so reference these new functions? Or does the svn binary reference these new functions? > Now the link fails citing unresolved symbols corresponding to the new > functions (and only the new functions not any of the old functions). > Which link? Linking libsvn_ra-1.so or the svn binary? > I find the libtool inter-library documentation confusing, but I think this > is a Debian bug simply because Debian's libtool fails and GNU's libtool > appears to work. Is there some reason that Debian's libtool is not allowed > to work the same way as GNU's libtool (rpath perhaps)? I have another > machine with Debian libtool 1.5.2-1 installed and that doesn't show the > problem, it works like GNU libtool. > The reason is that otherwise if you change the SONAME of a library deep in the dependency chain (e.g. libpng) you have to recompile *every* shared library and binary above it -- which in Debian is just about everything. What's going wrong here is that when it links to the intermediate library (libsvn_ra-1.so) it can find a copy of its dependencies so checks them for consistency. By removing the installed copy, it just can't find them, so doesn't bother to check. Adding -Wl,--rpath -Wl,/path/to/dependency/libs to the link line seems to cure the problem. We probably need to be more intelligent and rather than simply ripping out the dependency_libs and just take out the -l lines and leave the paths in for the linker to find. > One final point: while investigating this I grabbed the Debian source for > libtool 1.5.6-3 and I was surprised to see that libtool is a native package, > with a .tar.gz rather than an .orig.tar.gz and a .diff.gz. Does libtool > really qualify to be a native package? It makes it harder to determine > the differences between Debian and upstream. > This was probably an accident, though I can't see why it would've happened. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
