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.