Re: [musl] [PATCH 1/1] ldso: continue searching if wrong architecture is found first

[Thorsten Glaser <tg@mirbsd.de>]

i262jq@0w.se dixit:

>I wonder how the loader would distinguish between "right" and "wrong"
>if there are multiple libraries differing for example only in some minor

That is precisely what we wondered about for the time_t-64-on-ILP32
transition in Debian.

>build option - which difference still can be crucial for the actual
>application or for other used libraries?

tl;dr: random build options cannot be distinguished. You have the
flags in the ELF header, which have CPU architecture and bitness,
and (other than x32 (amd64ilp32) and arm64ilp32, from there on it
gets machine-dependent as you need to define per-architecture ABI
flags, e.g. EABI vs. old ABI or MIPS o32 vs n32 vs n64.

So this will always be some kind of system-global at least, if not
world-global, thing, not something for the odd application or admin
to decide.

>Is it really worth to make LD_LIBRARY_PATH "more usable", but still unsafe?

I still think so.

>To the contrary, relying on the explicit loader in a wrapper is totally
>safe, because the path to the libraries is not inherited at any later
>exec.

What if the first binary you run is not the one that needs to get the
changed library path, but the binaries it runs?

>Are there any practical cases where the overhead of an extra execve()
>of a small wrapper would be a noticeable problem?

It may be very hard to get these into the right places.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)