From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10461 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Deploying a dynamic executable on glibc systems - how? Date: Thu, 15 Sep 2016 11:14:26 -0400 Message-ID: <20160915151426.GH15995@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1473952497 4732 195.159.176.226 (15 Sep 2016 15:14:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Sep 2016 15:14:57 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-10474-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 15 17:14:53 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1bkYN6-0007hC-Is for gllmg-musl@m.gmane.org; Thu, 15 Sep 2016 17:14:40 +0200 Original-Received: (qmail 7341 invoked by uid 550); 15 Sep 2016 15:14:40 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 7317 invoked from network); 15 Sep 2016 15:14:39 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10461 Archived-At: On Thu, Sep 15, 2016 at 02:20:27PM +0100, Jon Chesterfield wrote: > Hi all, > > I have just been through the process of shipping a program built on a > recent glibc system for use on an old one. This has left me looking for an > alternative. > > In general, I like the approach of statically linking everything and > shipping the single enormous binary. This solves the compatibility problems > in exchange for removing dynamic linking. > > Unfortunately I also like dlopen and the combination of static linking and > dlopen is an unhappy one. > > My thoughts on resolving this are: > 1/ link the entire musl libc into a static main executable > 2/ put all the symbols in a table analogous to a plt in this executable > 3/ hack the loader to look in said table > 4/ open plugin using dlopen > > The idea is to keep main static enough that it doesn't need the system > loader to start, yet dynamic enough that libc can be exported. > > However, "first hack the loader" suggests there may be a better way. I'm > essentially looking for a way of deploying an application that can load > plugins without also installing the musl loader to the host. Can someone > see a better solution? The simplest way to achieve what you want is a shell script that does: exec "$loc/ld-musl-$arch.so.1" -- "$loc/your.bin" "$@" The location $loc could be hard-coded at install time or the script could derive it from its own location somehow. This doesn't achieve single-file deployment but it is very easy to do. A more elaborate idea is to make a utility that glues together a collection of ELF files into a single executable. But in order for the result to successfully execute, some different code is needed so that the dynamic linker knows where to find the (glued-in) main program entry point and knows the names of all the libraries (so that it doesn't try to load them again when it sees them as dependencies for DT_NEEDED entries of dlopen'd libraries). Some minor changes could probably be made to the loader code to make this work. Ideally the necessary data for the loader to use to make sense of the glued-together libs and main program should be something clean in the ELF scheme of things that other implementations could adopt (so the same glue-together tool could be used with glibc, etc.) Alternatively we could make static-linked dlopen work, but this is complicated and has lots of its own difficulties. Rich