[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#317082: Not just a dpkg bug



> objdump isn't a solution either, while it sometimes can read the other
> shared library, it doesn't provide the linker search patch which is of
> critical importance to get this stuff right.

Hmm...
But what for is that search path?
As far as I understand, dpkg-shlibdeps should just get NEEDED sonames, and 
match those against available shlibs files.

And that is what code actually does. Path information is used only if 
something is not found in this way - that means, package that provides the 
library does not provide shlibs data, which is a bug anyway.

So looks it is safe to remove any path processing from dpkg-slibdeps, and 
use only objdump. If something breaks, it should be fixed elsewhere (i.e. 
proper shlibs data added to packages).

But anyway, this is not enough: 32bit and 64bit versions of a library are 
likely to have same sonames, so they can't be distinguished within the 
current shlibs file format. Complete fix should probably add one more 
field to shlibs files - the binary format.

So a possible way to fix this is:
- add binary format field to slibs file format [for backward-compatability, 
the field should be optional and default to 'normal' binary format for the 
architecture; packages providing such extended shlibs data should conflict 
with dpkg-dev versions that don't support it]
- fix dpkg-shlibdeps: don't call ldd; use objdump both to extract NEEDED 
and to get binary format; add extended shlibs format handling;
- fix any packages that happen to depend on [just removed] dpkg-shlibdeps 
support of no shlibs information.

Attachment: pgpdCIpalltEz.pgp
Description: PGP signature


Reply to: