Re: A question about pure static linking with libdl

[Rich Felker <dalias@libc.org>]

On Sat, Jun 10, 2017 at 06:37:33PM +0200, Szabolcs Nagy wrote:
> * Jon Chesterfield <jonathanchesterfield@gmail.com> [2017-06-10 12:19:43 +0100]:
> > I think using dlopen in static binaries is an interesting (though niche)
> > use case. I'm subscribed to this list with a vague intention of
> > implementing it but haven't found the time.
> > 
> > The application of interest to me is a plugin architecture where the main
> > executable is static, mostly so it's easier to distribute, and the plugged
> > in components are independent of any libc. Essentially trying to use elf as
> > part of a jit loading mechanism.
> > 
> > No eta on this work though. Could be years :(
> 
> to do that the application must contain everything from libc
> that may be needed by the loaded plugins (since you dont want
> to load another libc when one is already static linked)
> 
> the easiest way is to just put all of libc into your application
> (or put your application into libc: e.g. put your application code
> into the musl repo and change the dynamic linker startup code to
> jump to your app, then the produced libc.so will do dynamic linking
> and then runs your app, dlopen works and it's a self-contained binary)
> 
> otoh this wont work well for loading jited code: if you generate
> lot of executable code, then you will need unload support too to
> get rid of the unused contents, in musl dlclose is a noop so the
> address space will keep filling up.

For the jit'd code usage case I think it makes more sense to just
write your own minimal ELF loader that's not tied into the global
symbol table and dynamic linking semantics. Then you can unload it
freely and don't have to worry about interaction with other things.
Perhaps someday I should write a poc for doing this. It should only
take a few hundred loc and should be essentially arch-independent just
like musl's relocation code (just needing arch-reloc-to-generic
mappings like musl uses).

Rich