On 2012-09-30 08:41, Rob T wrote:
There are plenty of cases where you have to use a dynamically loaded lib
even if you know before hand what will be loaded. I think you understand
this if I read your posts correctly.
In my case I have a pre-existing C++ app that is designed to load user
defined C++ plugins. I wanted to interface D to one of my own C++
plugins, but I apparently cannot do it reliably because of
initialization issues with the GC and possibly some other obscure items.
But now we're back at plugins. I think this part of the discussion is
starting to run in circles and become quite pointless. I think most of
us know that we need to support all types of libraries. Static and
dynamic, both for link time and runtime.
If I can figure out what needs to be done to resolve the problem in
enough detail, then maybe I can hack the runtime source and roll out a
solution.
You can have a look at the work done by Martin Nowak:
https://github.com/dawgfoto/druntime/commits/SharedRuntime
He has a couple of other useful branches as well, for example:
https://github.com/dawgfoto/druntime/commits/dmain2Refactoring
On Mac OS X there's also the problem with TLS. There is no native
support for TLS in Mac OS X prior to Lion (10.7). DMD has rolled its own
implementation that needs to be adapted to support dynamic libraries.
The GC always seems to pop up as a source of problems. For long term
solution, the GC should be made 100% optional (in practice as opposed to
in theory), the standard library ought to be made to work with or
wothout a GC (or simply without), and the GC itself should be easily
replaceable with alternate versions. I think this idea has already been
discussed elsewhere, and is on the TODO list (I hope!).
You can replace the GC at link time. Here's an example of a stubbed
implemented of the GC:
http://dsource.org/projects/tango/browser/trunk/tango/core/rt/gc/stub
This is for Tango but the druntime is based on the Tango runtime so I
would guess most of this would be the same.
--
/Jacob Carlborg
