Re: Alternative solution to stat storm problem

[Ludovic Courtès]

Hi,

Tom Scogland <scogland1@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’.