Re: static linking and dlopen

[Szabolcs Nagy <nsz@port70.net>]

* croco@openwall.com <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)