From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6842 Path: news.gmane.org!not-for-mail From: u-wsnj@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: OT: Re: dynamic linking (Re: [musl] musl and android) Date: Thu, 15 Jan 2015 16:56:38 +0100 Message-ID: <20150115155638.GB14316@example.net> References: <20150115161322.4ee903b7@sibserver.ru> <20150115110158.GN4574@brightrain.aerifal.cx> <20150115120004.GY14316@example.net> <20150115121536.GO4574@brightrain.aerifal.cx> <20150115130432.GZ14316@example.net> <20150115133445.GQ4574@brightrain.aerifal.cx> 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 1421337431 23473 80.91.229.3 (15 Jan 2015 15:57:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2015 15:57:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6855-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 15 16:57:06 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YBmnB-0002Lu-V2 for gllmg-musl@m.gmane.org; Thu, 15 Jan 2015 16:57:06 +0100 Original-Received: (qmail 20267 invoked by uid 550); 15 Jan 2015 15:57:04 -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 20258 invoked from network); 15 Jan 2015 15:57:03 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe02.swip.net; client-ip=95.130.11.147; envelope-from=u-wsnj@aetey.se Content-Disposition: inline In-Reply-To: <20150115133445.GQ4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6842 Archived-At: Actually I do not suggest any change, musl suits my usage model well (kudos for the support of running the loader explicitly)! On Thu, Jan 15, 2015 at 08:34:45AM -0500, Rich Felker wrote: > That's why I said i depends on your perspective. From your perspective > this does not work. From most traditional distributions' perspectives, > it does. Well said. The traditional distributions choose to live with the far reaching consequences of their technical choices. I argue that some constraints (iow sacrifices) are not necessary and only exist as a consequence of the unfortunate choices. > > Unfortunately, no. $ORIGIN does not and can not replace a run time > > choice of the dynamic loader. > If you're distributing the binary and dynamic loader/libc and all > libraries it needs together, I'd assume they'd all be in the same > directory, or else in ../lib/ relative to the binary. In that case You suggest a somewhat more relaxed set of assumptions than the traditional ones. Yes this would be useful, but unfortunately still setting some more or less arbitrary boundaries. > $ORIGIN works perfectly fine. Note that $ORIGIN is _not_ an > environment variable; it's a dynamic-linker feature for locating > libraries relative to the ELF file (main executable or other library) > that needs (via DT_NEEDED) them, and the same concept would work for > PT_INTERP. Indeed, good to point this out for a casual reader. Using an environment variable would be otherwise a quite general solution but I guess this would be very hard to convince the kernel developers to implement (presumably hardly possible to implement without redesigning the kernel security model). Regards, Rune