gdc so files

[Kirk McDonald]

Sclytrack wrote:
> I was wondering is this the right method of doing .so files? Because in the
> windows dll example one starts another garbage collector. Here no extra
> garbage collector is started, or not that I'm aware of.
> 
> In the likely event that I won't thank you afterwards.
> 
>      Thanks in advance, Sclytrack
> 
> 
> Go D, Go !!!

Here is Pyd's "boilerplate" module for compiling .so's on Linux. As the 
comments note, it has some problems:

/*python_so_linux_boilerplate.d*/
// This file requires the .so be compiled with '-nostartfiles'.
// Also note that this is inferior to the Windows version: it does not 
call the
// static constructors or unit tests. As far as I can tell, this can't 
be done
// until Phobos is updated to explicitly allow it.
extern(C) {

void gc_init();
void gc_term();

void _init() {
     gc_init();
}

void _fini() {
     gc_term();
}

} /* extern(C) */
/*EOF*/

_init and _fini are special functions in shared objects which are called 
on initialization and finalization of the library. At some point I'll be 
fleshing this thing out more (I think I now know how to add static 
constructor and unittest support, for instance).

The -nostartfiles point is important: gcc has default versions of these 
functions that it will want to link in. If you end up using both this 
and GCC's version, it gets very confused. -nostartfiles tells it to not 
use the defaults, so these can be used instead.

These days, _init and _fini are deprecated in favor of some built-in GCC 
macros. These are obviously not available in D. Their use in Pyd is 
safe, since the only thing loading the shared object is Python, which is 
quite good about calling these functions. The concern is that it is 
possible for programs to load an .so and somehow skip the call to one or 
the other of _init or _fini. I am not sure quite how serious of a 
concern it is; perhaps someone more familiar with the problem can chime in.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org