On Fri, Jan 20, 2006 at 11:57:28AM +0300, Nikita V. Youshchenko wrote: > > 2) we could try to use the ldconfig cache to make to work of ldd for > > ourself. > > Questions: - Is this really an advantage? Or has the cache the same > > problems ldd has? Hmm. In theory, ldconfig shouldn't require the ability to execute 64-bit binaries in order to build a cache of their paths. The only thing I don't know is how 64-bit vs. 32-bit libs are cached? It would after all have to be possible to distinguish between them in order to use the cache for this. > > 3) we could parse /etc/ld.so.conf and search for the libraries ourself. > > this is essentially a more general version of the current way > > dpkg-cross works AFAICS I think the only question here is whether it's appropriate for dpkg to have its own internal representation of the library search path, since that means duplicating information between glibc and dpkg. IMHO, this is still the least-bad option. > > 4) we could just parse _all_ shlib files, perhaps even generating a > > cache from them. > > Questions: - Seems a complex solution (if it uses caching). Is any of > > the simpler solutions feasible? > > - How slow is this? > I believe this is *the* correct way. > If should be *much* faster than calling dpkg -S - just because dpkg -S > actually loads all *.list files, which is many times larger than *.shlibs > files. > As I side effect, this will allow to remove LD_LIBRARY_PATH thing from > dh_shlibdeps, which gives some unwanted effects when cross-compiling > packages (like finding cross version of libz.so.1 in LD_LIBRARY_PATH and > refusing to load native binaries that link against libz.so.1). > The only question is that is will *require* packages to provide valid > shlibs.local files. Hrm? It shouldn't; dpkg-shlibdeps is already capable of checking shlibs files within the build directory. > One more question that came to mind right now: is it possible that more > than one installed package provides shlibs infomation for the same soname? Yes, AFAIK *every* biarch package is going to provide shlibs for libraries that differ only by library path, not by soname. So that's not very useful for solving the problem at hand. > From the other hand, what is the wanted behaviour in this case? If you aren't able to distinguish the libraries according to the path of the library they provide, the *only* sensible thing to do in such a case is to bail. > As for that question, AFAIK library filename and soname are completely > unrelated. So there may be a soname 'ABCDE' that is provided by libxxx.so. > A binary linked against that library will get 'NEEDED ABCDE'. And dynamic > linker and ldd will find it, as long as there is 'ABCDE' symlink or file > in dynamic linker search path. Uh, consequently they are *not* unrelated: the soname specified in NEEDED *must* be a filename that exists on the system, be it symlink or otherwise, and per policy this file must be contained in the library package (as opposed to just being created by ldconfig on package install). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature