[opensuse-packaging] Automatic Dependencies of libraries
Hi everybody, some mails just earlier made me check some of my packages (vlc from the vlc repo). I've seen one thing that puzzles me a bit and which I consider a source for possible problems at this moment. Just some simple output to 'show' my case: dle3ams@3120-2914:/usr/lib64/vlc/access> ldd libvcdx_plugin.so | grep iso9660 libiso9660.so.7 => /usr/lib64/libiso9660.so.7 (0x00007f5bf6709000) dle3ams@3120-2914:/usr/lib64/vlc/access> rpm -qf libvcdx_plugin.so vlc-noX-1.0.1-2.1 dle3ams@3120-2914:/usr/lib64/vlc/access> rpm -q --requires vlc-noX | grep iso9660 dle3ams@3120-2914:/usr/lib64/vlc/access> So in human words: the package vlc-noX contains a libvcdx access plugin which itself depends on libiso9660.so.7. The package vlc-noX OTOH does not have this requirement in it's table. So if somebody installs this package, there is at least this dependency not being pulled in automatically. How can this happen and even more important: how can we avoid it? (well I see one option, but that's rather surprising to me: the same file also depends on libvcdinfo.so.0, which in turn itself has a dependency on libiso9660.so.7. Is this already enough to consider not to list this dependency? This in return would break if there was any other implementation of libvcdinfo.so.0 that would not depend on libiso9660.so.7 (statically linked or whatever the cause would be). At the moment I'm just puzzled... and I'm eager to hear explanations that are able to take away my fear of things like this breaking around us. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 18/08/09 14:33, Dominique Leuenberger wrote: the same file also
depends on libvcdinfo.so.0, which in turn itself has a dependency on libiso9660.so.7. Is this already enough to consider not to list this dependency?
Yes, that's the way it should be... ;)
This in return would break if there was any other implementation of libvcdinfo.so.0 that would not depend on libiso9660.so.7 (statically linked or whatever the cause would be).
No, it will not break and if it does the application is at fault.
At the moment I'm just puzzled... and I'm eager to hear explanations that are able to take away my fear of things like this breaking around us.
read this document http://www.gentoo.org/proj/en/qa/asneeded.xml -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 8/18/2009 at 20:39, Cristian Rodríguez
wrote: On 18/08/09 14:33, Dominique Leuenberger wrote: the same file also depends on libvcdinfo.so.0, which in turn itself has a dependency on libiso9660.so.7. Is this already enough to consider not to list this dependency? At the moment I'm just puzzled... and I'm eager to hear explanations that are able to take away my fear of things like this breaking around us. read this document
Thanks for this link.. I'll for sure invest the time in reading (and hopefully understanding) it. i'm a bit scared by this. What would happen if libvcdinfo could be compiled without iso9660 support, but during my build time was build with the support? then my resulting lib has a dependency (by rpm) to libvcdinfo, the .so itself lists libiso9660 when checking with ldd, but the libvcdinfo I install (a later rebuild without the iso9660 support) was built without that support, it's going to break. Why would this now be the 'fault' of the application / original lib linking? I think this simply increases the risk of breaking when not using exactly the same library (incl. dependency chain) on the machine that was used when building the entire stack, no? Dominique (of course the example is now a bit fictive.. vcdinfo will probably always depend on iso9660.. except if for example a future, still api / abi compatible version has all the external dependency built in). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 18/08/09 14:50, Dominique Leuenberger wrote:
i'm a bit scared by this.
What is scary is the myriad of issues that changing the linker to the previous behavior will cause, most notably.. a) a HUGE dependency bloat in libraries and binaries. b) There will be no practical way to stop libtool insanity.
Why would this now be the 'fault' of the application / original lib linking? I think this simply increases the risk of breaking when not using exactly the same library (incl. dependency chain) on the machine that was used when building the entire stack, no?
if applications, libraries or modules actually _use_ a library (aka. include its headers) MUST link those libraries _explicitly_. There is another case where apps load libraries at runtime and with dlopen() and link with -ldl, this will fail anyway, rpm dependency extractor, at least last time I checked, wasnt able to handle this case. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 18 Aug 2009 15:05:58 -0400, you wrote:
rpm dependency extractor, at least last time I checked, wasnt able to handle this case.
It can't as there is no dependency recorded in the ELF header of a binary (the place where directly needed libraries are recorded for use by the dynamic linker). Such runtime dependencies must be taken care of by the packager. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/8/19 Philipp Thomas
On Tue, 18 Aug 2009 15:05:58 -0400, you wrote:
rpm dependency extractor, at least last time I checked, wasnt able to handle this case.
It can't as there is no dependency recorded in the ELF header of a binary (the place where directly needed libraries are recorded for use by the dynamic linker). Such runtime dependencies must be taken care of by the packager.
Could not the first argument of every dlopen call be obtained from the ELF file? Perhaps if debuginfo is available could be done? Since this came... I sometimes read about rpm dependency extractors for java/python/mono/whatever, but I don't really package too much things in non-compiled languages and I never follow it. Righy now, exactly when RPM can extract dependencies automatically? For compiled languages/ELF binaries and... something else? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Wed, 19 Aug 2009, Cristian Morales Vega wrote:
Could not the first argument of every dlopen call be obtained from the ELF file? Perhaps if debuginfo is available could be done?
char *n = construct_something(); l = dlopen (n, RTLD_LAZY);
Since this came... I sometimes read about rpm dependency extractors for java/python/mono/whatever, but I don't really package too much things in non-compiled languages and I never follow it. Righy now, exactly when RPM can extract dependencies automatically? For compiled languages/ELF binaries and... something else?
/usr/lib/rpm/find-requires [1] (The other find* scripts in there might interest you too). Ciao, Michael. [1] In short: ELF objects, script interpreters, mono executables, kernel symbols. Support for perl modules exists, but requirement generation is deactivated (it automatically generates provides, though). Support for tcl and python modules is prepared but not implemented. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/8/19 Michael Matz
Hi,
On Wed, 19 Aug 2009, Cristian Morales Vega wrote:
Could not the first argument of every dlopen call be obtained from the ELF file? Perhaps if debuginfo is available could be done?
char *n = construct_something(); l = dlopen (n, RTLD_LAZY);
D'oh!
Since this came... I sometimes read about rpm dependency extractors for java/python/mono/whatever, but I don't really package too much things in non-compiled languages and I never follow it. Righy now, exactly when RPM can extract dependencies automatically? For compiled languages/ELF binaries and... something else?
/usr/lib/rpm/find-requires [1]
Thanks. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2009/8/18 Dominique Leuenberger
i'm a bit scared by this. What would happen if libvcdinfo could be compiled without iso9660 support, but during my build time was build with the support? then my resulting lib has a dependency (by rpm) to libvcdinfo, the .so itself lists libiso9660 when checking with ldd, but the libvcdinfo I install (a later rebuild without the iso9660 support) was built without that support, it's going to break.
I think the whole confusion is because of ldd. ldd does *not* lists the needed dependencies of a library, it lists the whole library dependency tree in the *current* system. ldd output for the same file can be different in different machines. To obtain the list of libraries really needed by libvcdx_plugin.so you can use "readelf -d libvcdx_plugin.so" | fgrep NEEDED or "objdump -p libvcdx_plugin.so | fgrep NEEDED". Just that in openSUSE 11.1 that lists includes libraries that... yes, if aren't available the library will fail to load, but then its code isn't used at all. In openSUSE 11.2 that lists only includes libraries that are *really* needed/used. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 19/08/2009 at 12:44 AM, Cristian Morales Vega
wrote: I think the whole confusion is because of ldd. ldd does *not* lists the needed dependencies of a library, it lists the whole library dependency tree in the *current* system. ldd output for the same file can be different in different machines.
Thanks for this explanation. This really explains the confusion. I blindly assumed that the rpm dependency should somewhat reflect the ldd output. Everyday the knowledge of a human being increses.. Thanks for this. Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
Cristian Morales Vega
-
Cristian Rodríguez
-
Dominique Leuenberger
-
Michael Matz
-
Philipp Thomas