Dynamic D Library

Benji Smith dlanguage at benjismith.net
Thu Jul 16 18:10:43 PDT 2009


Jarrett Billingsley wrote:
> On Thu, Jul 16, 2009 at 4:44 PM, teo<teo.ubuntu at yahoo.com> wrote:
> 
>>>  For two, there is *no problem*
>>> with creating D libraries on any platform other than Windows, and it
>>> is entirely through Windows' fault that it has the problems it does
>>> with DLLs.
>>>
>> Well, let us assume that you can create dynamic libraries in D and you need to include in each of them Phobos (later maybe just the D Runtime). What is the benefit of that? Can you imagine all your nice dynamic libraries (DLLs, SOs, etc.) written in D and all of them including a huge “payload”? Wouldn't it be better just a simple library only containing the stuff you need?
> 
> I don't think you're getting it.
> 
> ON WINDOWS, DLLs are not allowed to have unresolved externals.  So if
> you create a DLL in D, yes, Phobos will be linked in.  THERE IS
> NOTHING THAT CAN BE DONE ABOUT THAT.  It's a limitation on the way
> DLLs work.
> 
> ON EVERY OTHER OPERATING SYSTEM (Linux, Unix, OSX, *whatever*), shared
> libraries CAN have unresolved externals, so Phobos *does not* have to
> be included in the shared libraries.  Shared libraries ALREADY work
> the way you expect them to on every OS besides Windows.
> 
> The ONLY way to solve the problem with DLLs on Windows is to not use
> DLLs.  Java solves it by not using any platform-dependent libraries,
> instead using its own .class files.  This is *exactly* what DDL does.
> 
> So, I'm not sure what you see as the problem here.  DDL works fine on
> Windows.  Use it.

You learn something new everyday. That's pretty cool.

Incidentally, this is exactly the kind of stuff that I'd love to see 
built right into DRuntime or Phobos.

I don't have a use for it right now (cuz my project is simple enough not 
to need dynamic loading), but in the future, I'd be reluctant to use DDL 
because:

1) Dynamic loading is something that, to me, seems completely 
fundamental to the runtime system, and I'd be hesitant to trust a 
third-party library to keep up-to-date with the current compiler & 
standard library.

2) DDL isn't even really a third-party library. It's more like a 
fourth-party, since (I assume) it really requires the h3r3tic patch to 
work correctly.

Building this kind of functionality into the standard library would make 
those issues irrelevant.

These kinds of issues are the ones that excite me the most and are the 
things I'd like to see D pay the most attention to. From my perspective, 
features of the runtime and standard library are often much more 
compelling than new language features.

--benji



More information about the Digitalmars-d mailing list