Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 17 Jun 2020 21:40:53 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Jeffrey Walton <noloader@...il.com>
Cc: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: Is Musl responsible for runpath parsing in an elf file?

* Jeffrey Walton <noloader@...il.com> [2020-06-15 21:25:15 -0400]:
> On Mon, Jun 15, 2020 at 9:16 PM Rich Felker <dalias@...c.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.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.