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<[email protected]> 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
