Hi,
Tom Scogland 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
Hi Farid,
Farid Zakaria skribis:
[...]
>> I guess the advantage is that you don’t need the ld.so patch. The
>> downside is that PatchELF needs to be able to write longer NEEDED
>> strings in the dynamic section, which it may not always be successful at
>> (I think?).
>
> I can't claim to be a
Hi Ludovic, thanks for your thoughts.
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
I did forget to mention the point of LD_LIBRARY_PATH, that you can
still make use of LD_PRELOAD and I am also thinking about maybe using
something like dlopen-resolver[1] to further expand the NEEDED
section.
[1] https://github.com/Mic92/dlopen-resolver
On Sat, Jan 8, 2022 at 7:00 PM Farid
Hi Ludovic,
On Sat, Jan 8, 2022 at 1:22 PM Ludovic Courtès wrote:
>
> Hi Farid,
>
> Farid Zakaria skribis:
>
> > I have written a tool _shrinkwrap_ [2] that takes all transitive
> > dynamic shared object dependencies (only those listed in DT_NEEDED)
> > and turns them into an absolute path.
> >
Hi Farid,
Farid Zakaria skribis:
> I have written a tool _shrinkwrap_ [2] that takes all transitive
> dynamic shared object dependencies (only those listed in DT_NEEDED)
> and turns them into an absolute path.
>
> This has the same result as caching the entries and avoids the
> unnecessary
Hi!
I was very inspired by the blog post on a per-application
ld.so.conf.cache to solve the stat-storm problem[1].
I wanted to share here another approach I am pursuing and seek to
eventually try to merge into NixOS however I thought starting a
discussion here on Guix would be fruitful since it