Re: [musl] is RUNPATH being incorrectly inherited inherited?

[Tom Scogland <scogland1@llnl.gov>]

On 12 Jan 2022, at 19:46, Farid Zakaria wrote:

> Hi Rich,
>
> Thank you for taking the time to read my email and responding.
> I was worried it was a bit too pedantic in explanation and I had had
> some trivial error in the setup.
> (I am only beginning to gain deeper knowledge on linking)
>
> On Wed, Jan 12, 2022 at 7:29 PM Rich Felker <dalias@libc.org> wrote:
>>> To me this means that the ld.so here is not respecting the description
>>> of not propagating the search paths to the children.
>>
>> Yes, that's intentional. Is this something you want not to happen?
>
> This specific case, I only brought up after having read the manpage
> for linux-ld/ld.so
> on my quest to better understand dynamic linkers. It does seem that
> other tools are making similar assumptions
> however (libtree) when trying to replicate the search pattern employed
> by a linker.
>
> The rationale you mention about the ability to set a single top-level
> RUNPATH is desirable however
> I do find the delta between what's documented for ld.so to have been confusing.
>
> I am as part of some research evaluating other alternatives to how to
> specify link-paths and part of that
> research direction involves more explicitly specifying whether a path
> should/should not be inherited; in addition to a
> few other ideas.
>
> It's clear you are aware of this discrepancy and it was done so knowingly.
> At least I know I was not mis-understanding the results of my setup :)

Adding a bit of extra context here, it’s not so much that we want it not to propagate (although I can work up examples where that’s what we would want) as it is that the System-V specification says it doesn’t propagate so this is pretty surprising behavior.  In a way it’s good, in that it means musl will work with QT-style plugin loading even when using runpath, but it’s also unfortunate in that we have no way to override LD_LIBRARY_PATH as a package builder when we know there are dirty environment modules on a system that set LD_LIBRARY_PATH to non-sensical values (I really wish this were not a problem).

What I think we actually want doesn’t currently exist anywhere, which is a way to specify search paths before and after LD_LIBRARY_PATH and whether they do or do not propagate.  There are cases where overriding LD_LIBRARY_PATH is desirable, along with many where it isn’t, and cases where propagation is harmful, along with many where it isn’t.  We’re trying to figure out what one would do if we were designing something like DT_NEEDED and DT_RUNPATH today, and I’d be interested in what you would want, or not want, out of that if you have further thoughts on the matter.

>>> FWIW, as per the other correspondence, if I remove part of the
>>> RUNPATH, then the binary fails to load even though _libx.so_ was
>>> already present.
>>
>> This is expected given the current lack of SONAME processing because,
>> while it's present, it's not tracked as being "what you should get by
>> resolving the name libx.so". If we do adopt SONAME processing here it
>> would be found, and would necessarily preclude any path search from
>> happening since it would already be present. Presumably that's what
>> you would want to happen, right?
>
> Yes! This is more of an interesting quirk I find different between
> glibc whose functionality
> I think would make a positive addition. Happy to continue discussing
> this issue on the other
> mailing list emails :)

Yes, that would actually help a good deal in making what we’re trying to do more robust.  It would also make things more consistent.  So far it seems most implementations fall into two buckets: either doing soname processing, and using soname for deduplication; or pretending the basename is the soname and using that, well or using soname if it exists and basename if not.  I think musl is the only one I’ve run into that works based on inode rather than some proxy for library name.

-Tom