From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2440 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: static linking and dlopen Date: Sun, 9 Dec 2012 12:46:08 +0100 Message-ID: <20121209114608.GG23126@port70.net> References: <20121208225237.GV20323@brightrain.aerifal.cx> <50C3CA75.8000504@comcast.net> <20121209063658.GA2925@openwall.com> <20121208232529.79bab53a.idunham@lavabit.com> <20121209100846.GB2925@openwall.com> 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 1355053580 22776 80.91.229.3 (9 Dec 2012 11:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Dec 2012 11:46:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2441-gllmg-musl=m.gmane.org@lists.openwall.com Sun Dec 09 12:46:34 2012 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 1ThfL6-00075k-N7 for gllmg-musl@plane.gmane.org; Sun, 09 Dec 2012 12:46:32 +0100 Original-Received: (qmail 25600 invoked by uid 550); 9 Dec 2012 11:46:20 -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 24568 invoked from network); 9 Dec 2012 11:46:20 -0000 Content-Disposition: inline In-Reply-To: <20121209100846.GB2925@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2440 Archived-At: * croco@openwall.com [2012-12-09 14:08:46 +0400]: > packages for them all, or I opt for -static). So, I'd like to have all the > libs inside the binary of, e.g., my interpreter (actually, this can be a > program which does its job being controlled by embedded interpreter). But, > at the same time, it is very possible I need these loadable modules, which dalias just described why static linking with dlopen is not possible (he also specifically mentioned interpreters using dlopen..) > loaded must itself use statically-linked version of libraries so that some > functions will be loaded to the code segment twice. Such practice should > be discouraged but I don't think it should be made impossible at all. it is impossible two version of the same function cannot go together: they may work correctly only if some global state exists only once or modified from a single place (malloc with brk pointer and exit with file stream list were such examples) so you can use dlopen only if you can ensure you don't use the same libraries as the dlopened code or all shared code is pure (no writeable global state, no sideeffects), but if you use dlopen you already depend on libc and if the dlopened code also uses libc you have a problem (different library version was an additional issue) so you can have dlopen in your static interpreter if 1) you know all the dlopened code and verified that they don't depend on libc or anything impure on which the interpreter depends (but in this case you should link those statically) 2) include all the dependent libraries entirely into the statically linked binary and have dlopen use the symbols from these (for which you may need to modify the linker and make sure the binary is not stripped or implement dlopen so it somehow has a list of all the extern symbols) (but this does not seem practical and still does not solve abi breaking library versioning issues)