DMD workforce contribution

[Jacob Carlborg]

On 2011-11-07 13:36, Gor Gyolchanyan wrote:
>> 1. Making shared libraries under Linux work would be a big improvement.
>
> I think you meant "Making shared libraries, written in D, under Linux
> work would be a big improvement.", because everything else works fine
> (i tested it) using core.sys.posix.dlfn;
> Since druntime needs some serious initialization, core.sys.windows.dll
> was invented to hide away all this and, if I'm not mistaken, this is
> precisely what it means to "support DLLs".
> since .so files don't have any auto-called functions, like DllMain,
> some additional shenanigans are required to get it to work as in
> Windows. There will still be helper functions that would be put inside
> some "main" function in .so functions, that should be called
> explicitly when loaded (probably inside a standard library loader).
> DllMain also has thread/process attach/detach routine callbacks, which
> are, AFAIK, are not necessary to simulate in .so files (otherwise,
> it'll go inside that pseudo-main function).
> Regarding the above information, all I have to do to make "shared
> libraries work under linux" is to make linux analogs for the dll
> helper functions, define the pseudo-main function requirement in D
> docs and make a specialization of LoadLibrary routine in druntime to
> call that function.
>
> I have a question regarding the general approach to shared libraries
> in D: Should we really use obsolete C library formats and jump through
> lots of hoops to work around the limitations?
>
> AFAIK, currently "DLL support" is purely an optional druntime feature,
> that allows one to quickly initialize druntime from DllMain by using
> the functions for attaching/detaching a thread/process.
> I understand, the GC, some handlers (like exception handler) as well
> as any other things i don't know about should be properly initialized.
> The problem is, that .so files in ELF format don't have anything similar.
> In order to make the two consistent some common logic should be
> developed on how does D treat

There is a GCC extension available for this:

__attribute__((constructor))

http://stackoverflow.com/questions/2053029/how-exactly-does-attribute-constructor-work

Oh, BTW, generating PIC needs to be fixed first. In addition to the GCC 
attribute Mac OS X also have a couple of low level functions for working 
with the dynamic linker:

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/dyld.3.html

Don't know if there's something similar available on Linux.

-- 
/Jacob Carlborg