Thanks to the efforts of Martin Nowak (dawgfoto) I have been able to build druntime as a shared library under Linux64 and get it to successfully run the test suite.

Therefore, it's now time to make this now the default. This requires some changes to the makefiles for druntime, phobos, and some tweaks to dmd.

druntime:
    PIC needs to default to -fPIC
    dll is now the default build

phobos:
    DRUNTIME needs to default to being nothing

dmd:
    prepend "-ldruntime-linux64" to the list of standard libraries passed to the linker

dmd.conf:
    needs -L-Lpath/druntime/lib added to DFLAGS

and,
    export LD_LIBRARY_PATH=path/druntime/lib
needs to be executed by the user.

Once this is all working for Linux64, we can extend it to the other platforms.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

2013/3/13 Walter Bright <walter@digitalmars.com>

> Thanks to the efforts of Martin Nowak (dawgfoto) I have been able to build druntime as a shared library under Linux64 and get it to successfully run the test suite.
>
> Therefore, it's now time to make this now the default. This requires some changes to the makefiles for druntime, phobos, and some tweaks to dmd.


It is very nice to hear that problems which you expect to not been fixed soon are actually being fixed.

Currently D object file is statically linked to phobos archive which includes druntime as well. After this changes druntime would be expelled from phobos library, right?

What about dynamic loading support of user-written modules?

On 03/13/2013 08:01 AM, Walter Bright wrote:
> Thanks to the efforts of Martin Nowak (dawgfoto) I have been able to build druntime as a shared library under Linux64 and get it to successfully run the test suite.
>
> Therefore, it's now time to make this now the default. This requires some changes to the makefiles for druntime, phobos, and some tweaks to dmd.
>
> druntime:
>     PIC needs to default to -fPIC
>     dll is now the default build
>
> phobos:
>     DRUNTIME needs to default to being nothing
>
> dmd:
>     prepend "-ldruntime-linux64" to the list of standard libraries passed to the linker
>
> dmd.conf:
>     needs -L-Lpath/druntime/lib added to DFLAGS
>
> and,
>     export LD_LIBRARY_PATH=path/druntime/lib
> needs to be executed by the user.
>
> Once this is all working for Linux64, we can extend it to the other platforms.
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>
>
We could alternatively include the complete druntime archive in the shared phobos library.
dmd -shared ... -L--whole-archive -L-l$(DRUNTIME) -L--no-whole-archive.

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

This is absolutely fantastic, many thanks to everyone involved and Martin in particular!

One question - shouldn't we preserve the current default (static linking throughout)? Last thing I want is to hear naysayers clamoring how we threw them in DLL hell whereas other languages (which don't support DLLs in the first place) don't.

Dynamic linking is a great option and possibly the best way going forward, but at least for the time being let's not make it the default until we make it rock solid.


Thanks,

Andrei

On 3/13/13 3:01 AM, Walter Bright wrote:
> Thanks to the efforts of Martin Nowak (dawgfoto) I have been able to
> build druntime as a shared library under Linux64 and get it to
> successfully run the test suite.
>
> Therefore, it's now time to make this now the default. This requires
> some changes to the makefiles for druntime, phobos, and some tweaks to dmd.
>
> druntime:
> PIC needs to default to -fPIC
> dll is now the default build
>
> phobos:
> DRUNTIME needs to default to being nothing
>
> dmd:
> prepend "-ldruntime-linux64" to the list of standard libraries passed to
> the linker
>
> dmd.conf:
> needs -L-Lpath/druntime/lib added to DFLAGS
>
> and,
> export LD_LIBRARY_PATH=path/druntime/lib
> needs to be executed by the user.
>
> Once this is all working for Linux64, we can extend it to the other
> platforms.
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/13/2013 1:46 AM, Maxim Fomin wrote:
>
>
> 2013/3/13 Walter Bright <walter@digitalmars.com <mailto:walter@digitalmars.com>>
>
>     Thanks to the efforts of Martin Nowak (dawgfoto) I have been able to build
>     druntime as a shared library under Linux64 and get it to successfully run
>     the test suite.
>
>     Therefore, it's now time to make this now the default. This requires some
>     changes to the makefiles for druntime, phobos, and some tweaks to dmd.
>
>
> It is very nice to hear that problems which you expect to not been fixed soon are actually being fixed.
>
> Currently D object file is statically linked to phobos archive which includes druntime as well. After this changes druntime would be expelled from phobos library, right?

That's right.

>
> What about dynamic loading support of user-written modules?
>

This is a necessary step to get there.

On 3/13/2013 8:51 AM, Martin Nowak wrote:
> We could alternatively include the complete druntime archive in the shared phobos library.
> dmd -shared ... -L--whole-archive -L-l$(DRUNTIME) -L--no-whole-archive.

I'm not sure what that does. Does it mean there is only one binary a user has to ship? What if two such binaries are run at once - do they share the druntime.so?
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/13/2013 10:43 AM, Andrei Alexandrescu wrote:
> This is absolutely fantastic, many thanks to everyone involved and Martin in particular!
>
> One question - shouldn't we preserve the current default (static linking throughout)? Last thing I want is to hear naysayers clamoring how we threw them in DLL hell whereas other languages (which don't support DLLs in the first place) don't.
>
> Dynamic linking is a great option and possibly the best way going forward, but at least for the time being let's not make it the default until we make it rock solid.

I don't think we can make it rock solid until we make it the default!

_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

Hi,

On Wed, Mar 13, 2013 at 7:28 PM, Walter Bright <walter@digitalmars.com> wrote:
>
> On 3/13/2013 10:43 AM, Andrei Alexandrescu wrote:
>>
>> This is absolutely fantastic, many thanks to everyone involved and Martin in particular!
>>
>> One question - shouldn't we preserve the current default (static linking throughout)? Last thing I want is to hear naysayers clamoring how we threw them in DLL hell whereas other languages (which don't support DLLs in the first place) don't.
>>
>> Dynamic linking is a great option and possibly the best way going forward, but at least for the time being let's not make it the default until we make it rock solid.
>
>
> I don't think we can make it rock solid until we make it the default!

While I can see where you're coming from, let's not rush things.

We need to make _at least_ one release with shared library support that has to be selected explicitly with a -shared flag. We cannot just disrupt everyone by throwing shared libraries at them with no prior warning or testing having happened.

Regards,
Alex
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/13/2013 11:32 AM, Alex Rønne Petersen wrote:
> While I can see where you're coming from, let's not rush things. We need to make _at least_ one release with shared library support that has to be selected explicitly with a -shared flag. We cannot just disrupt everyone by throwing shared libraries at them with no prior warning or testing having happened.


I can pretty much guarantee that if we don't make shared druntime the default, nobody is going to use it, and it will not work.

For example, while Martin had made all these shared library changes, as far as I can tell:

1. nobody even tried to make druntime.so

2. even after I checked in the makefile changes to build druntime.so, nobody tried to run the test suite on it

3. at least for 32 bit druntime.so, any program built with it promptly crashes. Nobody noticed this, so I am pretty sure nobody has tried it. (llmath is the culprit, I have a pull request in to fix that)

There are also significant problems with trying to ship the current scheme *and* the dll scheme. The libraries are built differently, the dmd.conf is different, etc. It's a problem, and I don't see a convenient solution for coexistence. If there is a way to statically bind druntime.so as Martin suggested, that could be the solution, but it is still having druntime.so being the default.

It's early in this cycle, so it's the best time to do it.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On Wed, Mar 13, 2013 at 8:13 PM, Walter Bright <walter@digitalmars.com> wrote:
>
> On 3/13/2013 11:32 AM, Alex Rønne Petersen wrote:
>>
>> While I can see where you're coming from, let's not rush things. We need to make _at least_ one release with shared library support that has to be selected explicitly with a -shared flag. We cannot just disrupt everyone by throwing shared libraries at them with no prior warning or testing having happened.
>
>
>
> I can pretty much guarantee that if we don't make shared druntime the default, nobody is going to use it, and it will not work.

Contrary to this, I have seen many people ask (both on the NG, IRC, and elsewhere) for an option to build shared libraries.

The thing is that on Linux (and other Unixy platforms), shared libraries are the preferred way to do libraries nowadays. People will use it just as they use GCC to make shared libraries. With GCC, you have to be explicit about it, too. If we were talking about Windows, I would probably agree with you, since there's not really any pseudo-standard there.

I remember when we first announced initial shared library support in DMD (i.e. the -shared flag). *Lots* of people were trying it out, but of course to no avail at the time.

So how about this: Instead of speculating, why don't we try making just one release where static linking is still the default and you have to explicitly ask for shared linking? Then we'll see what happens. Worst case, we just go ahead and make shared linking the default on Linux in the next release.

>
> For example, while Martin had made all these shared library changes, as far as I can tell:
>
> 1. nobody even tried to make druntime.so
>
> 2. even after I checked in the makefile changes to build druntime.so, nobody tried to run the test suite on it
>
> 3. at least for 32 bit druntime.so, any program built with it promptly crashes. Nobody noticed this, so I am pretty sure nobody has tried it. (llmath is the culprit, I have a pull request in to fix that)

The only reason I didn't test all of the changes is that I figured I'd wait until they were all merged.

>
> There are also significant problems with trying to ship the current scheme *and* the dll scheme. The libraries are built differently, the dmd.conf is different, etc. It's a problem, and I don't see a convenient solution for coexistence. If there is a way to statically bind druntime.so as Martin suggested, that could be the solution, but it is still having druntime.so being the default.

The way to deal with both libdruntime.so and libdruntime.a existing on a system is to explicitly ask for libdruntime.a when desired (note the .a). The linker will prefer the shared library when just -ldruntime is passed. So no dmd.conf change should be necessary with regards to linking; DMD just has to do the right thing depending on whether -shared was passed.

I don't think the libraries being built differently is going to be a problem in practice unless I'm missing something?

>
> It's early in this cycle, so it's the best time to do it.
>
> _______________________________________________
> D-runtime mailing list
> D-runtime@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime