DMD workforce contribution

[Gor Gyolchanyan]

> I think that a programming language that declares itself as a "System Language" should be able to build and use native shared libraries.

You're completely right. Just as D supports extern(C) to support
C-function, it should support C-libraries. But this doesn't mean, that
this is the way it should work always.
At the end, all shared libraries are always usable, because they need
a C API and D can interface with C APIs. There can even be neat
high-level wrappers around those APIs to ease the access to C shared
libraries.
But I think encouraging programmers to wrote _new_ libraries in _D_
using those shared library formats is a bad idea. Too many
workarounds, too much danger.

> There is the DDL project with that approach: http://www.dsource.org/projects/ddl/wiki

I knew about DDL a long time ago. But it's D1 only and doesn't seem to
be willing to add D2 support. If and when it supports D2, I'll take a
look at it, test it for various traits and if it passes the tests I'll
make a pull request to add it to Phobos.

On Tue, Nov 8, 2011 at 10:45 AM, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> There is the DDL project with that approach:
> http://www.dsource.org/projects/ddl/wiki
>
> I think that a programming language that declares itself as a "System
> Language" should be able to build and use native shared libraries.
>
> On 08.11.2011 07:32, Gor Gyolchanyan wrote:
>>
>> Is there any ready plan, that will describe what exactly do we want to
>> get in the end?
>> I'm starting to think, that it would be great to have our own format
>> for shared libraries.
>>
>> On Tue, Nov 8, 2011 at 10:25 AM, Rainer Schuetze<r.sagitario at gmx.de>
>>  wrote:
>>>
>>>
>>> On 07.11.2011 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.
>>>
>>> There are different ways to use and implement shared libraries written in
>>> D:
>>> 1. the shared library interfaces to any other library as a C library
>>> does,
>>> i.e. without any shared resources (e.g. it has its own heap and its own
>>> thread list).
>>> 2. the shared library shares resources with other libraries and the
>>> executable.
>>>
>>> The DLL support on windows covers the first case. I think such a shared
>>> library should work in any host application, even if it is not aware that
>>> it
>>> is written in D.
>>>
>>> There is limited support for the second case that only forwards calls to
>>> the
>>> GC into another shared library, but it won't work with other resources or
>>> in
>>> a multi threading environment.
>>>
>>> Some attempts have been made to put the phobos runtime library into a
>>> shared
>>> library on Windows (and OSX):
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=4071
>>>
>