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