public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/30306] New: ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ?
@ 2023-04-03 13:47 jason.vas.dias at gmail dot com
2023-04-03 13:57 ` [Bug libc/30306] " jason.vas.dias at gmail dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jason.vas.dias at gmail dot com @ 2023-04-03 13:47 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=30306
Bug ID: 30306
Summary: ld.so.conf could easily / should support binary
specific LD_PATH directory search path settings ?
Product: glibc
Version: unspecified
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: libc
Assignee: unassigned at sourceware dot org
Reporter: jason.vas.dias at gmail dot com
CC: drepper.fsp at gmail dot com
Target Milestone: ---
I am considering developing a patch to ld.so's ld.so.conf handling
that , as well as supporting DIRECTORY lists to add to the effective
LD_PATH ($LD_LIBRARY_PATH), could easily also support a new syntax like:
/usr/bin/perf:+/usr/local/lib64
to create an EXCEPTION for the /usr/bin/perf program,
so that for the specific binary file /usr/bin/perf,
/usr/local/lib64 would be added to the
"effective $LD_LIBRARY_PATH" := LD_PATH
(my shorthand).
Perhaps an alternative on platforms which support filesystems
with extended attributes would be to support files having
a 'LD_SO_PATH:' Extended Attribute, which ld.so could support
with some new
/${DIRECTORY}/:EA_LD_SO_PATH:true
setting to enable EA LD_SO_PATH checking for all files under
${DIRECTORY} .
This is to solve this problem:
https://bugzilla.redhat.com/show_bug.cgi?id=2183758
where the linux kernel 'perf' package from v6.2.8 cannot build
without the libbpf 0.8.0+ packages, but only v0.7.0 packages
come with FC36, so I need to build libbpf-1.1.0-2 into /usr/local/,
so it installs its libraries into /usr/local/lib64, then I DO build
perf with the ld / gcc '-R /usr/local/lib64' option, but this is
conscientiously stripped out of LDFLAGS / from resultant binaries,
I don't want to have to patch the binary, so I have to replace
/usr/bin/perf with a script :
'
!#/bin/bash
exec /usr/bin/perf.bin "$@"
', which is not ideal.
I think ld.so could provide a most elegant, simple & efficient
solution to this problem with support for a tiny extra bit of new
configuration syntax - I'd like my ld.so to provide this!
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/30306] ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ?
2023-04-03 13:47 [Bug libc/30306] New: ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ? jason.vas.dias at gmail dot com
@ 2023-04-03 13:57 ` jason.vas.dias at gmail dot com
2023-04-03 16:41 ` schwab@linux-m68k.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: jason.vas.dias at gmail dot com @ 2023-04-03 13:57 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=30306
--- Comment #1 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---
Oops, of course my /usr/bin/perf script has to be:
'
!#/bin/bash
declare -x LD_LIBRARY_PATH=/usr/local/lib64
exec /usr/bin/perf.bin "$@"
',
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/30306] ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ?
2023-04-03 13:47 [Bug libc/30306] New: ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ? jason.vas.dias at gmail dot com
2023-04-03 13:57 ` [Bug libc/30306] " jason.vas.dias at gmail dot com
@ 2023-04-03 16:41 ` schwab@linux-m68k.org
2023-04-03 19:09 ` jason.vas.dias at gmail dot com
2023-04-12 17:59 ` adhemerval.zanella at linaro dot org
3 siblings, 0 replies; 5+ messages in thread
From: schwab@linux-m68k.org @ 2023-04-03 16:41 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=30306
--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
Why can't you just add /usr/local/lib64 unconditionally to /etc/ld.so.conf?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/30306] ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ?
2023-04-03 13:47 [Bug libc/30306] New: ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ? jason.vas.dias at gmail dot com
2023-04-03 13:57 ` [Bug libc/30306] " jason.vas.dias at gmail dot com
2023-04-03 16:41 ` schwab@linux-m68k.org
@ 2023-04-03 19:09 ` jason.vas.dias at gmail dot com
2023-04-12 17:59 ` adhemerval.zanella at linaro dot org
3 siblings, 0 replies; 5+ messages in thread
From: jason.vas.dias at gmail dot com @ 2023-04-03 19:09 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=30306
--- Comment #3 from Jason Vas Dias <jason.vas.dias at gmail dot com> ---
RE: Comment #2:
> Why can't you just add /usr/local/lib64 unconditionally to /etc/ld.so.conf?
Thanks, Andreas -
Because there may be many other libraries in /usr/local/lib64 - in fact,
there is a libgcc-shared.so and a libstdc++.so.6 in /usr/local/lib64,
which I'd rather not pick up at all - I want to be able to move
libbpf's libraries to some /usr/local/libbpf-v1.1.0/lib64 directory ,
and specify that they apply ONLY to links needed for /usr/bin/perf,
I do NOT want these updated libbpf* links to update the system
libbpf at all, which MUST remain at v0.7.0, else everything that
uses libbpf (except perf) will break .
It just seems to me that having some very simple extra config
in ld.so.conf, to apply a LD_PATH only to certain executables,
would prevent a whole host of error prone disasters involved
with binary patching in of a DT_RUNPATH ELF note .
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libc/30306] ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ?
2023-04-03 13:47 [Bug libc/30306] New: ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ? jason.vas.dias at gmail dot com
` (2 preceding siblings ...)
2023-04-03 19:09 ` jason.vas.dias at gmail dot com
@ 2023-04-12 17:59 ` adhemerval.zanella at linaro dot org
3 siblings, 0 replies; 5+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2023-04-12 17:59 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=30306
Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |adhemerval.zanella at linaro dot o
| |rg
--- Comment #4 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Jason Vas Dias from comment #3)
> RE: Comment #2:
> > Why can't you just add /usr/local/lib64 unconditionally to /etc/ld.so.conf?
>
> Thanks, Andreas -
>
> Because there may be many other libraries in /usr/local/lib64 - in fact,
> there is a libgcc-shared.so and a libstdc++.so.6 in /usr/local/lib64,
> which I'd rather not pick up at all - I want to be able to move
> libbpf's libraries to some /usr/local/libbpf-v1.1.0/lib64 directory ,
> and specify that they apply ONLY to links needed for /usr/bin/perf,
> I do NOT want these updated libbpf* links to update the system
> libbpf at all, which MUST remain at v0.7.0, else everything that
> uses libbpf (except perf) will break .
>
> It just seems to me that having some very simple extra config
> in ld.so.conf, to apply a LD_PATH only to certain executables,
> would prevent a whole host of error prone disasters involved
> with binary patching in of a DT_RUNPATH ELF note .
We already have RPATH, which has precedence over the loader cache and it is not
subject to DF_1_NODEFLIB. RPATH also accepts $ORIGIN, which does not tie where
the binary is installed; and it is also simpler to use since do not need admin
credential (to update ld.so.config and run ldconfig).
I don't have a strong opinion, but this seems to just replicate a subset of
RPATH and it will add an extra complexity on loader cache (which will need to
keep track of whether the entry has a path associated, and add a new type to
handle the directory suggestion).
It also adds some corner cases:
- should it just support ET_EXEC?
- For ET_DYN, should it tie to the filesystem name or with its SONAME?
- The LD_LIBRARY_PATH is handled earlier than the cache and it is not subject
to DF_1_NODEFLIB, however your suggestion ties with LD_LIBRARY_PATH.
So I am not sure if this will be really an improvement.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-04-12 17:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-03 13:47 [Bug libc/30306] New: ld.so.conf could easily / should support binary specific LD_PATH directory search path settings ? jason.vas.dias at gmail dot com
2023-04-03 13:57 ` [Bug libc/30306] " jason.vas.dias at gmail dot com
2023-04-03 16:41 ` schwab@linux-m68k.org
2023-04-03 19:09 ` jason.vas.dias at gmail dot com
2023-04-12 17:59 ` adhemerval.zanella at linaro dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).