From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4813 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: MUSL_LIBRARY_PATH ? Date: Sun, 6 Apr 2014 12:18:27 -0400 Message-ID: <20140406161827.GY26358@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396801129 7287 80.91.229.3 (6 Apr 2014 16:18:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Apr 2014 16:18:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4817-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 06 18:18:42 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WWpmL-00059X-U6 for gllmg-musl@plane.gmane.org; Sun, 06 Apr 2014 18:18:42 +0200 Original-Received: (qmail 32501 invoked by uid 550); 6 Apr 2014 16:18:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32493 invoked from network); 6 Apr 2014 16:18:40 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4813 Archived-At: 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