|
Message-ID: <20140406161827.GY26358@brightrain.aerifal.cx> 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.