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