Date: Sun, 9 Dec 2012 14:08:46 +0400 From: croco@...nwall.com To: musl@...ts.openwall.com Subject: Re: static linking and dlopen On Sat, Dec 08, 2012 at 11:25:29PM -0800, Isaac Dunham wrote: > I think there's a misunderstanding here: > > musl includes a dlopen function. > When a binary is statically linked, it is a stub. > When a binary is dynamically linked, it loads the shared library requested. Oh, well, I didn't catch the situation; if this is the case, the things are definitely better. However, to my mind, static linkage is good for creating portable binaries (besides all the other advantages), and I can easily imagine a situation in which I dislike the idea of a dynamically-linked main binary (e.g. I ship some unusual software to endusers, and they have different Linux distros but are not going to build the soft from sources - yes, there are such Linux users who panic when they hear the word "compiler" - and I've got no hope someone else will package my soft for different distros, because it is too unusual, so either I spend my time installing 20+ different versions of various distros and prepare 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 extend the functionality of the interpreter. Surely it is not a catastrophe, as I can link all libs but musl statically, and provide libmusl.so along with the binary, also having a script which sets LD_LIBRARY_PATH and then runs the binary; but it is a bit, errr... /strange/ :) Actually, when it comes to -static, the linker only picks the modules that contain unresolved symbols, so it should (am I right?) be easy to break the things down to modules so that all the dynamic linkage mechanics is linked into the binary only in case it calls dlopen. And, okay, to mention in the man 3 dlopen that using it from within a statically-linked binary will increase the size of the binary by another megabyte, and that the .so to be 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. I realize, however, that it is possible I simply miss something. -- Croco
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.