Re: static linking and dlopen

[croco@openwall.com]

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