[musl] Is Musl responsible for runpath parsing in an elf file?

[musl] Is Musl responsible for runpath parsing in an elf file?

[Jeffrey Walton]

Hi Everyone,

Please forgive my ignorance... Is Musl responsible for runpath parsing
during elf loading? If it matters, I'm working on Alpine Linux.

Jeff

Re: [musl] Is Musl responsible for runpath parsing in an elf file?

[Rich Felker]

On Mon, Jun 15, 2020 at 08:45:18PM -0400, Jeffrey Walton wrote:
> Hi Everyone,
> 
> Please forgive my ignorance... Is Musl responsible for runpath parsing
> during elf loading? If it matters, I'm working on Alpine Linux.

Yes, loading of all libraries except the dynamic linker itself (which
includes libc on musl) is the responsibility of the dynamic linker and
is performed in userspace.

When searching for a given library as a dependency (DT_NEEDED), musl's
processing of rpath/runpath uses the runpath of the shared object
that's depending on it and causing it to be pulled in, and continues
this resolution recursively backwards, potentially up to the main
program's runpath, if not found.

Rich

Re: [musl] Is Musl responsible for runpath parsing in an elf file?

[Jeffrey Walton]

On Mon, Jun 15, 2020 at 9:16 PM Rich Felker <dalias@libc.org> wrote:
>
> On Mon, Jun 15, 2020 at 08:45:18PM -0400, Jeffrey Walton wrote:
> > Hi Everyone,
> >
> > Please forgive my ignorance... Is Musl responsible for runpath parsing
> > during elf loading? If it matters, I'm working on Alpine Linux.
>
> Yes, loading of all libraries except the dynamic linker itself (which
> includes libc on musl) is the responsibility of the dynamic linker and
> is performed in userspace.
>
> When searching for a given library as a dependency (DT_NEEDED), musl's
> processing of rpath/runpath uses the runpath of the shared object
> that's depending on it and causing it to be pulled in, and continues
> this resolution recursively backwards, potentially up to the main
> program's runpath, if not found.

Thanks Rich.

I may have mis-filed this against Alpine:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/11655.

Is it expected behavior? Should I move it to Musl bug tracker?

Jeff

Re: [musl] Is Musl responsible for runpath parsing in an elf file?

[Szabolcs Nagy]

* Jeffrey Walton <noloader@gmail.com> [2020-06-15 21:25:15 -0400]:
> On Mon, Jun 15, 2020 at 9:16 PM Rich Felker <dalias@libc.org> wrote:
> > On Mon, Jun 15, 2020 at 08:45:18PM -0400, Jeffrey Walton wrote:
> > > Hi Everyone,
> > >
> > > Please forgive my ignorance... Is Musl responsible for runpath parsing
> > > during elf loading? If it matters, I'm working on Alpine Linux.
> >
> > Yes, loading of all libraries except the dynamic linker itself (which
> > includes libc on musl) is the responsibility of the dynamic linker and
> > is performed in userspace.
> >
> > When searching for a given library as a dependency (DT_NEEDED), musl's
> > processing of rpath/runpath uses the runpath of the shared object
> > that's depending on it and causing it to be pulled in, and continues
> > this resolution recursively backwards, potentially up to the main
> > program's runpath, if not found.
> 
> Thanks Rich.
> 
> I may have mis-filed this against Alpine:
> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11655.
> 
> Is it expected behavior? Should I move it to Musl bug tracker?

yeah i remember this discussion

https://sourceware.org/legacy-ml/binutils/2019-06/msg00014.html

i think there is no good solution, you have to figure
out the right level of escape magic for your build
system when passing runpath flags.

Re: [musl] Is Musl responsible for runpath parsing in an elf file?

[Jeffrey Walton]

On Wed, Jun 17, 2020 at 3:40 PM Szabolcs Nagy <nsz@port70.net> wrote:
>
> * Jeffrey Walton <noloader@gmail.com> [2020-06-15 21:25:15 -0400]:
> > On Mon, Jun 15, 2020 at 9:16 PM Rich Felker <dalias@libc.org> wrote:
> > > On Mon, Jun 15, 2020 at 08:45:18PM -0400, Jeffrey Walton wrote:
> > > > Hi Everyone,
> > > >
> > > > Please forgive my ignorance... Is Musl responsible for runpath parsing
> > > > during elf loading? If it matters, I'm working on Alpine Linux.
> > >
> > > Yes, loading of all libraries except the dynamic linker itself (which
> > > includes libc on musl) is the responsibility of the dynamic linker and
> > > is performed in userspace.
> > >
> > > When searching for a given library as a dependency (DT_NEEDED), musl's
> > > processing of rpath/runpath uses the runpath of the shared object
> > > that's depending on it and causing it to be pulled in, and continues
> > > this resolution recursively backwards, potentially up to the main
> > > program's runpath, if not found.
> >
> > Thanks Rich.
> >
> > I may have mis-filed this against Alpine:
> > https://gitlab.alpinelinux.org/alpine/aports/-/issues/11655.
> >
> > Is it expected behavior? Should I move it to Musl bug tracker?
>
> yeah i remember this discussion
>
> https://sourceware.org/legacy-ml/binutils/2019-06/msg00014.html
>
> i think there is no good solution, you have to figure
> out the right level of escape magic for your build
> system when passing runpath flags.

Man, I'm getting old. I forgot about that discussion.

My memory is not worth a shit anymore...

Jeff