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

Heads up: Changes in dpkg-shlibdeps directory search list



[ Please follow up on d-d and d-cross (M-F-T set). ]

Hi!

There are several cleanups and order changes in the pipe for the default
dpkg-shlibdeps shared library directory search list in dpkg 1.18.x.

It was previously, in decreasing order of preference:

  0. «dpkg-shlibdeps -l» (or via «dh_shlibdeps -l»)
  1. ENV{LD_LIBRARY_PATH} (deprecated)
  2. DEFAULT_LIBRARY_PATH (/lib, /usr/lib)
  3. DEFAULT_MULTILIB_PATH (/lib32, /usr/lib32, /lib64, /usr/lib64,
                            /emul/ia32-linux/lib, /emul/ia32-linux/usr/lib)
  4. If cross-building or building a cross-compiler:
       cross-multiarch (/lib/<triplet>, /usr/lib/<triplet>)
       cross-root (/<triplet>/lib, /usr/<triplet>/lib)
       cross-root-multilib (/<triplet>/lib32, /usr/<triplet>/lib32,
                            /<triplet>/lib64, /usr/<triplet>/lib64)
  5. ld.so.conf

And will become:

  a. «dpkg-shlibdeps -l» (or via «dh_shlibdeps -l»)
  b. ENV{LD_LIBRARY_PATH} (obsolete)
  c. If cross-building or building a cross-compiler:
       cross-multiarch (/lib/<triplet>, /usr/lib/<triplet>)
  d. DEFAULT_LIBRARY_PATH (/lib, /usr/lib)
  e. ld.so.conf
  f. DEFAULT_MULTILIB_PATH (legacy: /lib32, /usr/lib32, /lib64, /usr/lib64)

And the rationale for the changes follows:

* Setting LD_LIBRARY_PATH in debian/rules to specify the local build-tree
  has been obsoleted by «dpkg-shlibdeps -l». That variable is for the
  run-time linker, using is also for the build-time environment mixes
  them up, and does not play nice when cross-building, if you've got a
  package doing that, please switch to use the option -l. I'll request
  a lintian check for this.

* The ancient GCC_TARGET environment variable is not honored anymore,
  this was a way to specify cross-compiler builds, DEB_TARGET_GNU_TYPE
  can always be used for that now.

* The cross-root directories (/<triplet>/lib* and /usr/<triplet>/lib*)
  are not added anymore to the default list when cross-building. These are
  legacy from a pre-multiarch era, no package uploaded to Debian should
  be using these, and having them in the default list is just an accident
  waiting to happen. Of course people using local cross-root setups can
  still use those paths, they will just not be used for *packaged*
  binaries, and if people still want to use these paths to package stuff
  outside of Debian they can still use «dpkg-shlibdeps -l».

* When cross-building the cross-multiarch paths should have precedence
  over the native ones, because that's what we are linking against. In
  theory when cross-building no native paths (b. sometimes, d. and f.)
  should be in the list, as that pollutes it, and I'm pondering about
  doing that, but we might need to keep loading ld.so.conf as foreign
  packages might have added required paths for cross-compiling there…

* The ancient multilib paths (/emul/ia32-linux/lib and
  /emul/ia32-linux/usr/lib) inherited from ia64 are gone now, these
  were transitioned away from in squeeze.

* The legacy multilib paths now have lower precedence than the ld.so.conf
  ones, as proper standard or multiarch paths should be always preferred,
  or programs might end up accidentally depending on multilib packages. In
  the near future I'd like to either remove or hide multilib paths from
  the default list if DPKG_ENABLE_DEPRECATED_MULTILIB=yes is not set in
  the environment (for example), to avoid polluting the default list, and
  because they are pretty much non-exhaustive and do not cover all
  current multilib paths anyway.

Thanks,
Guillem


Reply to: