On Tue, 09 Feb 2010 15:58:37 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> Steve Teale wrote:
>> The inability to do this is a real show-stopper for D on Linux, and unless things have got better since I last tried, the same can be said for Windows DLLs.
>
> The dmd/samples/d/dserver.d is an example of a Windows DLL in D.

According to Don (haven't tried, because I don't have a windows box handy), any D2 DLL will fail, even an empty one because of http://d.puremagic.com/issues/show_bug.cgi?id=3342

That aside, having to handle manual steps to ensure the runtime doesn't lose its mind is unacceptable.  It has to be handled without any manual runtime coding to be a viable solution.  DDL is not a solution, its a hack.

In other words, I should be able to flip a compiler switch to build a shared lib, and I shouldn't have to do anything special aside from exporting symbols.  This is the way it is in all other programming languages.

Until Phobos is a shared lib, I don't think we need to have any discussions about any existing solutions.  That is requirement number 1 for saying D supports shared libs.

-Steve

Walter Bright wrote:
> Steve Teale wrote:
>> The inability to do this is a real show-stopper for D on Linux, and unless things have got better since I last tried, the same can be said for Windows DLLs.
> 
> The dmd/samples/d/dserver.d is an example of a Windows DLL in D.

It doesn't work on D2 because of the TLS issue.

Steven Schveighoffer wrote:
> On Tue, 09 Feb 2010 15:58:37 -0500, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> Steve Teale wrote:
>>> The inability to do this is a real show-stopper for D on Linux, and unless things have got better since I last tried, the same can be said for Windows DLLs.
>>
>> The dmd/samples/d/dserver.d is an example of a Windows DLL in D.
> 
> According to Don (haven't tried, because I don't have a windows box handy), any D2 DLL will fail, even an empty one because of http://d.puremagic.com/issues/show_bug.cgi?id=3342

It is a bad problem, but it doesn't apply to implicitly loaded DLLs, only dynamically loaded ones, and it also doesn't apply to Vista or Windows 7.


> That aside, having to handle manual steps to ensure the runtime doesn't lose its mind is unacceptable.  It has to be handled without any manual runtime coding to be a viable solution.  DDL is not a solution, its a hack.
> 
> In other words, I should be able to flip a compiler switch to build a shared lib, and I shouldn't have to do anything special aside from exporting symbols.  This is the way it is in all other programming languages.
> 
> Until Phobos is a shared lib, I don't think we need to have any discussions about any existing solutions.  That is requirement number 1 for saying D supports shared libs.

Shared libraries (on Linux) and Windows DLLs are very different things.

Phobos as a DLL is a different problem than creating DLLs with D. DLLs in D can be created that are statically linked with Phobos, and that can be accessed by any executable in any language.

On Tue, 09 Feb 2010 16:28:27 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 09 Feb 2010 15:58:37 -0500, Walter Bright <newshound1@digitalmars.com> wrote:
>>
>>> Steve Teale wrote:
>>>> The inability to do this is a real show-stopper for D on Linux, and unless things have got better since I last tried, the same can be said for Windows DLLs.
>>>
>>> The dmd/samples/d/dserver.d is an example of a Windows DLL in D.
>>  According to Don (haven't tried, because I don't have a windows box handy), any D2 DLL will fail, even an empty one because of http://d.puremagic.com/issues/show_bug.cgi?id=3342
>
> It is a bad problem, but it doesn't apply to implicitly loaded DLLs, only dynamically loaded ones, and it also doesn't apply to Vista or Windows 7.

But implicitly loaded DLLs aren't supported by D!  However, I was not aware that it only applied to dynamically loaded ones, that is good to know.

>> That aside, having to handle manual steps to ensure the runtime doesn't lose its mind is unacceptable.  It has to be handled without any manual runtime coding to be a viable solution.  DDL is not a solution, its a hack.
>>  In other words, I should be able to flip a compiler switch to build a shared lib, and I shouldn't have to do anything special aside from exporting symbols.  This is the way it is in all other programming languages.
>>  Until Phobos is a shared lib, I don't think we need to have any discussions about any existing solutions.  That is requirement number 1 for saying D supports shared libs.
>
> Shared libraries (on Linux) and Windows DLLs are very different things.

Yes, I agree they are two different problems to solve.  But to a developer, they look the same.

> Phobos as a DLL is a different problem than creating DLLs with D. DLLs in D can be created that are statically linked with Phobos, and that can be accessed by any executable in any language.

They can be accessed by another D program?  My understanding is that all kinds of weird problems happen if you dynamically link two D programs together.  I'm not speaking from first-hand experience, I may be wrong.

It is very important that Phobos be a dynamic library and that you can build dynamic libraries easily without manual manipulation of the runtime.  If these two things are accomplished, then D can say it supports dynamic libraries, not before.  Half ass support doesn't count.  It's like saying a car has a cup holder because you can wedge your cup between the seat and the e-brake.

-Steve

Steven Schveighoffer wrote:
> But implicitly loaded DLLs aren't supported by D!

Sure they are, see the program in dmd/samples/d


>> Shared libraries (on Linux) and Windows DLLs are very different things.
> 
> Yes, I agree they are two different problems to solve.  But to a developer, they look the same.

They aren't the same, even to a developer, as they do different things and behave very differently.


>> Phobos as a DLL is a different problem than creating DLLs with D. DLLs in D can be created that are statically linked with Phobos, and that can be accessed by any executable in any language.
> 
> They can be accessed by another D program?  My understanding is that all kinds of weird problems happen if you dynamically link two D programs together.  I'm not speaking from first-hand experience, I may be wrong.

At a minimum, if you expose a C interface from your DLL, it can interact with any other DLL.


> It is very important that Phobos be a dynamic library and that you can build dynamic libraries easily without manual manipulation of the runtime.  If these two things are accomplished, then D can say it supports dynamic libraries, not before.  Half ass support doesn't count.

There's still a lot you can do with DLLs and D.

Steven Schveighoffer wrote:
> It is very important that Phobos be a dynamic library and that you can build dynamic libraries easily without manual manipulation of the runtime.  If these two things are accomplished, then D can say it supports dynamic libraries, not before.  Half ass support doesn't count.  It's like saying a car has a cup holder because you can wedge your cup between the seat and the e-brake.
> 
> -Steve

I agree, Steve.  Years ago when I did Windows programming with MFC
(Microsoft Foundation Classes), I had a preference for statically
linking the MFC libraries with my app to avoid the DLL hell problem.
However it was, and still is, possible to dynamically link with MFC
DLL's and this is often the preferred manner, if not the norm, for
Windows developers.  One could think of the Phobos runtime as being
analogous to the MFC runtime.  Why should there be different treatment,
i.e. you can do MFC programming with MFC DLL but not D programming with
Phobos DLL?  Ditto for shared objects under Linux.  If D is supposed
to be a "systems programming language", you expect that it be able to
do all manner of "systems things", including being able to do shared
object libraries and DLL's on the respective platforms.

Cheers,
Justin Johansson

On Tue, 09 Feb 2010 17:01:10 -0500, Walter Bright <newshound1@digitalmars.com> wrote:

> There's still a lot you can do with DLLs and D.

Yet nobody does, including Phobos.  I wonder why...

-Steve

On 2/9/10 16:53, Steve Teale wrote:
> When D2 is 'frozen', as a special treat would it be possible for it to be
> able to generate object files that could be converted into shared
> libraries, and for Phobos to be a shared library to support same.
>
> I have tried every which way I can think of to create shared libraries
> using D. The closest I have come is with the old 1.030 GDC, and even with
> that there are problems. I've tried to describe the current situation in
> some detail on the blog section of my<a href="http://
> www.britseyeview.com/GDC-newbie.html">GDC-newbie page</a>. It is too long
> to post on the newsgroup.
>
> The inability to do this is a real show-stopper for D on Linux, and
> unless things have got better since I last tried, the same can be said
> for Windows DLLs.
>
> Please!
> Steve

I've compiled a couple of libraries as shared/dynamic libraries (including tango) using gdc on Mac OS X. I can't remeber I had any problems.