Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Runtime.loadLibrary() and unloadLibrary() on POSIX. #211
I think the issue is that the patch itself is correct, but not enough to smoothly support shared libraries on Posix, because all kinds of stuff will still break behind your back. Martin already did some work on this in the branch at his repo he linked, but as far as I know, there is still some more to do – you might want to join forces.
Linking against shared libraries will work soon but loading shared libraries at runtime
I get it, that's like others GC'd/managed environments works(AppDomain.Unload in the CLR) and that sounds like a good plan for the future. However, (and this is just a thought) I think that a partial implementation of this feature that at least let the developer load D shared libraries would be very useful.
IMHO, this will be used mostly to load plugins, plugins will modify the environment and do random stuff. From the application point of view it's easier to just restart the process in order to reload the new "catalog" of plugins.
Developers can use dlopen for C shared libraries and loadLibrary for D shared libraries. I don't think unloadLibrary is that necessary at this point, it's always better to just restart the process. In the future, if there will be an implementation of unloadLibrary, it will just mark the library to be unloaded eventually by the Runtime/GC.
So I would vote for a partial implementation of 'loadLibrary' and defer 'unloadLibrary' until we can afford the unload libraries in a safe way by a shared Runtime, etc.
Again, this is just a thought.