[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Jun 2017 18:37:33 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: John Hu <heat0415@...il.com>
Subject: Re: A question about pure static linking with libdl
* Jon Chesterfield <jonathanchesterfield@...il.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.
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.
