-
-
Notifications
You must be signed in to change notification settings - Fork 600
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement dlopen for self-contained shared libraries. #278
Comments
Is this a duplicate of #137? Or is the twist here that the loaded library doesn't depend on anything in the executable? If you can avoid all the dependencies, why not launch it as a standalone executable and use IO or mmap for IPC?
I think the arguments here are well presented. I've been supporting dynamic loading for cosmopolitan libs in #137 and some other tickets, but given the aggressive optimizations that @jart is applying to remove any code that is not being used, I don't see how it can be made to work with arbitrary libraries that may depend on any code that was optimized away. Surely the libraries themselves can be made self-sufficient, but then one would need to make sure that all internal structures have the same format/size/etc. (similar to the |
Let's assume the library can use Then it can open and use its own copy of libc. This looks dangerous but can work. It requires some magic: preparing structures in memory that libc's dynamic loader is doing. I imagine that it's in the spirit of Cosmopolitan Libc. If someone will do this sort of crazy stuff, this is the only place where it can happen. Yes, running libraries in separate process and doing IPC is better. Also see https://github.com/google/sandboxed-api |
Also interesting idea (might not work): Instead of loading a shared library, run a new process. This new process act like dynamic loader and will resolve all the dependencies of the shared library (load other shared libraries, including libc and link with them). But it will interpret LOAD segments of ELF by allocating shared memory in |
Also see iree-org/iree#5504. |
What I'm doing in https://github.com/jacereda/cosmogfx is loading a shared binary liked against We could have the first (static) executable ( Does that make sense? |
This now exists, it's called cosmo_dlopen. |
TLDR: opening and using dynamic libraries from statically linked executable.
Use case:
I have a
.so
library that does not require any function from my executable. It may require loading other libraries though.I want to load and run the code from this library within my statically linked executable.
Also I want all dl-related functions (like
dl_iterate_phdr
,dladdr
) to work.Notes:
When performing dynamic linking I don't want the library to link to any code in my executable. E.g. if this library will use any libc function, the system
libc.so
will be opened and linked. It will use its own version oferrno
, its own view of__environ
, etc. It may introduce various sort of troubles but should work for at least some libraries. To make it working, we can prepare the same ABI of global variables and functions as the dynamic loader from glibc does.References:
The text was updated successfully, but these errors were encountered: