2011/4/16 Jeff Johnson <n3...@mac.com>:
>
> On Apr 16, 2011, at 11:34 AM, Per Øyvind Karlsen wrote:
>
>> 2011/4/16 Jeff Johnson <n3...@mac.com>:
>>> 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
>> libz.so.1()(64bit)
>> libz.so.1(ZLIB_1.2.0)(64bit)
>> libz.so.1(ZLIB_1.2.0.2)(64bit)
>> libz.so.1(ZLIB_1.2.0.8)(64bit)
>> libz.so.1(ZLIB_1.2.2)(64bit)
>> libz.so.1(ZLIB_1.2.2.3)(64bit)
>> libz.so.1(ZLIB_1.2.2.4)(64bit)
>> libz.so.1(ZLIB_1.2.3.3)(64bit)
>> libz.so.1(ZLIB_1.2.3.4)(64bit)
>> libz.so.1(ZLIB_1.2.3.5)(64bit)
>> $ 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
>> (0x00007f99798ff000)
>> 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.
No, for uClibc there's a complete toolchain for it living under
/usr/uclibc, which
has it's own elf interpreter
(/usr/uclibc/{lib/ld-uClibc.so.0,lib64/ld64-uClibc.so.0})
which everything is linking against and the libraries aren't anywhere
near ABI compatible, they might even be built with different options.
>
> 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
> Requires: libz.so.1()(64bit)
> 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
> Requires: uClibc(libz)
> It is in fact not even the right goal to add dependencies to prevent
> uClibc packages from using whatever ELF libraries are available.
No, that won't work, uClibc lives in a separate root that is not in the standard
library paths, it has a separate elf interpreter which everything links against,
and to make sure everything works outside the uClibc's root
(/usr/uclibc) as well,
rpaths are used.
Determining whether uClibc or not based on the elf interpreter used is
if anything
the closest you'll get to "right", considering this is how the linker
actually behaves.
>
> 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.
Considering the idea is to maintain a complete toolchain with several shared
libraries etc., the headaches of changing SONAME and adjusting any dependencies
accordingly should be rather obvious.
>
> 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.
Wrong, if you take a closer look at the code, you'll see that the
result of readlink()
placed on 'path' is never even used currently.
I'll be commenting out this code for now to avoid any further
confusion concerning
this..
Notice that the devel() dependencies generated does *not* add any dependencies
on any of the SONAME packages/provides at all and has *nothing* to
do/relate with
the current automatic symlink dependencies in place either
>
> 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
You're wrong in the assumptions made both wrt. devel() and uClibc(),
meaning that
I've either not written the code clearly enough, and/or caused by the
obvious lack
of documentation.
I will document this through blueprints on launchpad in the not so
distant future as
soon as I find the time.
--
Regards,
Per Øyvind
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
