On Apr 16, 2011, at 11:34 AM, Per Řyvind Karlsen wrote:
> 2011/4/16 Jeff Johnson <firstname.lastname@example.org>:
>> And so now we have the start of Yet More peculier dependencies,
>> not just devel(...) but now uClibc(...).
> Yes, this is to avoid conflicts with sonames linked against glibc, ie. see:
> [peroyvind@lappis rpm-5.3.9]$ echo /usr/uclibc/usr/lib64/libz.so.1.2.5
> | LD_LIBRARY_PATH= tools/.libs/rpmdeps -P
> elf(buildid) = 436568eecd8496e8648066fcacd79919833499b0
> $ LD_LIBRARY_PATH=/usr/uclibc/lib64 ldd /usr/uclibc/usr/lib64/libz.so.1.2.5
> linux-vdso.so.1 => (0x00007fff68dff000)
> libc.so.0.9.30.3 => /usr/uclibc/lib64/libc.so.0.9.30.3
> ld64-uClibc.so.0.9.30.3 =>
> /usr/uclibc/lib64/ld64-uClibc.so.0.9.30.3 (0x00007f99796f7000)
Note that the ldd will _ALWAYS_ display DT_NEEDED -> DT_SONAME linkages
because that is in fact exactly the ELF "feature":
Identical SONAME == Identical content
when usual library conventions are done correctly (i.e. different/incompatible content
always has different soname).
The example you gave is exactly what is _SUPPOSED_ to happen.
I'm almost certain that is even the intent: so that uClibc can interoperate
with existing ELF libraries.
Now for the package dependencies: You (or Mandriva) wish different policy for packages
than how ELF SONAMES are used. If the example you gave using
doesn't Just Work from all ELF executables, well that's no problem that
could or should be fixed with Yet More Package Dependencies like
It is in fact not even the right goal to add dependencies to prevent
uClibc packages from using whatever ELF libraries are available.
If Mandriva truly wants to segregate uClibc <-> other ELF linkages, then the
proper way to do that is to change the SONAMES to ensure that indeed, uClibc
links only uClibc specific libraries. It isn't terribly hard to
change the linkage line to make that happen.
If you want "preference" of uClibc dependent packages, well that can be done
too, just not in the ELF code in RPM. There's lots of ways to add dependencies
without scrapping-and-replacing (the _ONLY_ serious difference is a readlink(2)
call to follow a symlink gawd knows where before doing what RPM is already doing
with ELF dependencies, the rest is just strings) the existing mechanism in RPM.
All of the above comments apply equally to devel(...) and uClibc(...) namespaces.
Figure out some other means than scrapping-and-replacing the ELF dependency
code generation to do whatever you wish
73 de Jeff
Received on Sat Apr 16 18:44:01 2011
- application/pkcs7-signature attachment: smime.p7s