Library init methods for using D shared libs in a non-D executable.

See rt_init() and rt_term(). They're declared in that very same file, I believe.

Are you sure that works, Sean? He's building a *nix shared lib, and it's not clear that the moduleInfo[] will be constructed properly for moduleCtor() to do the right thing?

Well, it DOES actually work if I call _init(); rt_init(); (and of course _fini(); and rt_term();" but I cannot use _init/_fini as methods in my own library and I have to define a different name for my library's _init/_fini.

Since I was finally able to get the whole runtime started in a pure C program, and even call a D lib function that uses Stdout, this ticket should be set to the lowest priority. It is only a minor enhancement to have a couple of clearly named tango-specific shared lib init functions instead of some odd extern's and the more obscure guessing of _init ; rt_init(); sequence. An API/headers specifically designed for this would be nice instead of simply extern'ing the needed methods and browsing tango internal runtime source code to get the names.

What are _init and _fini? If there are changes that need to be made to rt_init and rt_term, I'd love to know what they are. As for documentation of these routines--you're right. I think they're mentioned somewhere, but not any place obvious.

I think the _init and _fini is defined somewhere in a crt-something (C runtime?) object file that the D compiler links to when building the software lib.

This is so strange. I had the module constructors being run successfully in a small C++ program that loads the shared library (which is written in D of course). But I tried to load this same library in Sauerbraten, and for some odd reason, everything loads but the module constructors are not run (evidence: Stdout is null). I guess there is a symbol conflict somewhere but I do not understand what is happening.

I'd like to be able to load D libs from C/C++ applications, such as Apache for example, so that I can eventually make my own webserver out of MiniD. Now that would be awesome and much more interesting than PHP.

If you figure it out, please let me know. I'd be happy to make any necessary changes to get this working.

Hmm... I notice that gdc-tango's function for calling main (in dgccmain2.d) calls "initStaticDataPtrs();" as well as some other things. This "initStaticDataPtrs();" looks like it might be important but it is not extern'd so I cannot access it from my library code. Could someone please make this extern'd so I can possible use it? I still can't get the module ctors() to work in Sauerbraten but allocated dynamic arrays and assigning them values seem to work. Thank you.

This shouldn't be necessary. rt_init() calls this routine at the appropriate time.

Oh yeah, by the way I managed to get the D runtime working in Sauerbraten (C++) but not by loading it as a shared library. Instead, I built the D object files of my MiniD mod (*.o's) into the Sauerbraten executable with its other c++ objects and linked it all together with gdc. To get the module_ctors to run, I simply removed the call to _init and a simple rt_init/fini was enough.

It seems fairly stable and I've only encountered a glibc double-free crash once and that may or may not have been related to my MiniD + D runtime mod.