Hi, Tom Scogland <scogla...@llnl.gov> skribis:
> You’re right, the LD_LIBRARY_PATH will not change the loading order, > but using LD_PRELOAD will by the same mechanism we’re using, > pre-filling the cache with a library at the same soname. As part of > other explorations we’re doing around tweaking or wrapping the loader, > it may be possible to get semantics like LD_LIBRARY_PATH other ways, > but at the moment the goal is to make a program that will correctly > load all the dependencies it would have loaded were it run in the same > environment it was built in, despite LD_LIBRARY_PATH or RUNPATH in > dependencies or similar. Making a little tool that would override the > same way LD_LIBRARY_PATH would have would be relatively > straightforward though, would that be worth exploring do you think? Sure, why not. My approach was: take the loader and its mechanisms as they exist, and make the minimal changes needed to adapt it to the one-directory-per-package layout, when they currently assume FHS. The approach you describe is more about keeping the loader unchanged and working around its FHS assumptions “from the outside”. In that spirit, a separate mechanism for LD_LIBRARY_PATH-kind of user overrides might make sense. Thanks, Ludo’.
