From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5931 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: static build and dlopen Date: Wed, 27 Aug 2014 17:27:36 +0200 Message-ID: <20140827152735.GB22308@port70.net> References: 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 1409153276 11849 80.91.229.3 (27 Aug 2014 15:27:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2014 15:27:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5938-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 27 17:27:49 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 1XMf8W-0001MY-V1 for gllmg-musl@plane.gmane.org; Wed, 27 Aug 2014 17:27:49 +0200 Original-Received: (qmail 15865 invoked by uid 550); 27 Aug 2014 15:27:48 -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 15857 invoked from network); 27 Aug 2014 15:27:48 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:5931 Archived-At: * piranna@gmail.com [2014-08-27 16:14:07 +0200]: ... > thought libuv is calling to the system dlopen() function, it's said, > the musl stub for static builds, making it impossible to load the > Node.js compiled modules :-( dlopen does not work from a statically linked binary (it can be made to work but it's more complicated than it seems: the entire libc should be linked into the application so all interfaces are present a loaded module may require which partly defeats the purpose of static linking and there are toolchain issues with this so it is not implemented) > So I ask, does the dlopen() stub really makes sense (the linker is > intelligent enought to remove unused code on static builds...)? Is > there any alternative I can do? Is there a flag to allow to use the > real dlopen() function on static builds, or could it be possible to > add it? If not, could I be able to use an external dlopen library (and > could I be able to integrate it easily)? > if the loaded modules depend on the libc api (or transitively any external dependency) then naive dlopen cannot work with static linking and there is no way around this (btw the same applies to all module systems that can load libraries written in c, eg. if you tried a statically linked python you would have the same issue: it works if all dependencies are linked in, it fails if you load libraries at runtime) > Oh, and if you are thinking about it: yes, this is a farily similar > use case as when compiling OS kernels (at least hybrid ones, like > Linux) where you need to compile them statically so it can boot and > also has support to load compiled modules on runtime, since in this > case, Node.js is in fact the "kernel" and Linux is just a somewhat HAL > layer :-P neither the kernel nor the loaded kernel modules depend on the libc