From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6839 Path: news.gmane.org!not-for-mail From: u-wsnj@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: dynamic linking (Re: [musl] musl and android) Date: Thu, 15 Jan 2015 14:04:32 +0100 Message-ID: <20150115130432.GZ14316@example.net> References: <20150115161322.4ee903b7@sibserver.ru> <20150115110158.GN4574@brightrain.aerifal.cx> <20150115120004.GY14316@example.net> <20150115121536.GO4574@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 1421327108 7219 80.91.229.3 (15 Jan 2015 13:05:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2015 13:05:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6852-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 15 14:05:03 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 1YBk6h-000399-Kg for gllmg-musl@m.gmane.org; Thu, 15 Jan 2015 14:05:03 +0100 Original-Received: (qmail 25937 invoked by uid 550); 15 Jan 2015 13:04:54 -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 25929 invoked from network); 15 Jan 2015 13:04:53 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe07.swip.net; client-ip=5.196.178.66; envelope-from=u-wsnj@aetey.se Content-Disposition: inline In-Reply-To: <20150115121536.GO4574@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6839 Archived-At: On Thu, Jan 15, 2015 at 07:15:36AM -0500, Rich Felker wrote: > > > and executing the program via a wrapper script that manually invokes > > > the dynamic linker (so the hard-coded PT_INTERP pathname isn't > > > needed). > > Actually I believe (and know from long time experience) this to be > > the only "sane"/robust/general way to run dynamically linked executables. > > It depends on your perspective. If you're viewing them as > self-contained entities, then yes, but if you're viewing them as > something running in an existing library ecosystem, there's no > problem. Right, it depends. For the second perspective you seem to imply that an "ecosystem" is to be managed in a certain way. Binaries belonging to my "library ecosystems" still can be subject to the C library tests and upgrades on a per-binary basis, not only "all binaries belonging to the same ecosystem at once", which is of course possible as well. This would be impossible if I'd rely on the hardcoded loader path. > > I don't think that the implications of hardcoding the interpreter > > path were well understood when dynamic linking was first deployed, > > the hardcoding merely became percepted as the only/natural approach > > when the purpose was to cheaply imitate the behaviour of statically > > linked programs. (This mimics the #!/... which is similarly > > limited/broken. The plain text scripts are though relatively easy > > to modify to hack around the limitation, according to local curcumstances) > > I think this could be fixed easily by having the kernel support > $ORIGIN in PT_INTERP. Unfortunately, no. $ORIGIN does not and can not replace a run time choice of the dynamic loader. As a simple example, consider a binary on a readonly media. How would you convince the kernel to run a different loader than assumed (among others) by the path to the mount point of the media? In my eyes the mounting of the media (possibly with lots of binaries on it) and running a certain loader for a certain binary are very different things and do not have to / should not depend on each other. Rune