[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Apr 2014 12:18:27 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: MUSL_LIBRARY_PATH ?
On Sun, Apr 06, 2014 at 10:38:53AM -0400, John Mudd wrote:
> Thanks for the replies! I now have a proper ld-musl-i386.path file
> containing the paths for my libraries. I've unset LD_LIBRARY_PATH and my
> musl built Python works well.
>
> I'm still configuring musl with --syslibdir=/tmp/musl/lib/. I agree /tmp is
> a poor choice. But I use three different logins on my dev, test and prod
> machines and it's not practical to get root access on the test or prod PCs.
> So /tmp is a good place to at least run experiments.
>
> Any chance I can specify multiple (colon separated?) paths with
> the --syslibdir option? Or can I make it relative to the current user's
> home path by starting with "~"?
No, this is a kernel limitation. Processing the PT_INTERP header and
loading the dynamic linker from the pathname stored there is performed
by the kernel, and only absolute pathnames are supported. It would be
really nice if $ORIGIN expansion were supported by the kernel, but
it's not.
The obvious workaround is to put a shell script in place of your
actual binary, and have it do:
exec "$ldso" -- "foo.bin" "$@"
or similar. Alternatively a minimal static-linked binary could be used
instead of shell script to make it perform better and eliminate some
of the risks of shell script processing.
Another alternative (much more advanced) would be removing the
PT_INTERP header entirely from dynamic programs and instead static
linking into them some minimal loader code that would find and mmap
the dynamic linker and transfer control to it. IIRC this is actually
how a.out dynamic linking worked long, long ago.
Rich
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.
