From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4727 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: be able to break inheritance of LD_LIBRARY_PATH Date: Fri, 28 Mar 2014 14:17:19 +0100 Message-ID: <20140328131718.GH27448@port70.net> References: <20140328104208.GZ8221@example.net> 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 1396012641 18613 80.91.229.3 (28 Mar 2014 13:17:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2014 13:17:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4731-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 28 14:17:32 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 1WTWf6-000365-3b for gllmg-musl@plane.gmane.org; Fri, 28 Mar 2014 14:17:32 +0100 Original-Received: (qmail 17758 invoked by uid 550); 28 Mar 2014 13:17:31 -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 17750 invoked from network); 28 Mar 2014 13:17:31 -0000 Content-Disposition: inline In-Reply-To: <20140328104208.GZ8221@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4727 Archived-At: * u-igbb@aetey.se [2014-03-28 10:42:08 +0000]: > For our software setup it is crucial (quite useful otherwise in general) > to be able to specify the location of the dynamic libraries per binary/run > _without_ the unconditional inheritance imposed by LD_LIBRARY_PATH. why do you use LD_LIBRARY_PATH then? > A very nice solution would be the ability to explicitely run a standalone > dynamic loader, as implemented in both glibc and uclibc. We are heavily > relying on this functionality. what is a standalone dynamic loader and how does it solve the lib path? if you mean a separate binary from libc.so, that does not matter much (the loader and libc.so are interdependent on each other's internals anyway, they are one logical unit even if in two separate files) if you mean you can run '/lib/ld-linux.so.2 binary' then musl can do the same > As a simpler approach I might suggest simply being able to drop > LD_LIBRARY_PATH as soon as it has been read. An extra environment > variable as a flag would do. if you dont control the environment you will have other issues (eg with LD_PRELOAD) if you do control the env then just unset LD_LIBRARY_PATH > Compared to a standalone loader this lacks the ability to run > a binary with a different version of the loader/musl but at least > makes it straightforward and safe to freely specify where to find other > libraries. the loader is whatever the PT_INTERP says in the elf header of the binary, so you can set it per binary, but in general you want it to be the same everywhere so binaries are portable (there ar no "different versions of the loader" in musl) in case you do a lot of lib path hacks note that the path lookup is different in glibc than in musl: glibc: 1) DT_RPATH if no DT_RUNPATH is present (transitive) 2) LD_LIBRARY_PATH 3) DT_RUNPATH (eg set with --enable-new-dtags) (non-transitive) 4) /etc/ld.so.cache (except with -z nodefaultlib) 5) /lib:/usr/lib (except with -z nodefaultlib) musl: 1) LD_LIBRARY_PATH 2) DT_RPATH (transitive) 3) {interp}/../etc/ld-musl-arch.path or /lib:/usr/local/lib:/usr/lib