On Wed, 13 Mar 2013, Walter Bright 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.
> 
> 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.

It's been _possible_ for all of a few days.  There hasn't been an alpha or beta release with a .so pre-built.  It's hardly shocking that there's essentially zero experience with running it.

I fully agree with the "its too soon" sentiment.  There's a set of people that _really_ want it, and I think it's fairly safe to assume that they'll play and report issues.  No need to inflict the pain on everyone until SOME people have kicked the tires.  Reach out, engage with some people. Get SOME realish world testing done.


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

On 3/13/2013 12:32 PM, Brad Roberts wrote:

>
> I fully agree with the "its too soon" sentiment.  There's a set of people
> that _really_ want it, and I think it's fairly safe to assume that they'll
> play and report issues.  No need to inflict the pain on everyone until
> SOME people have kicked the tires.  Reach out, engage with some people.
> Get SOME realish world testing done.
>
>

It ain't real unless the autotester is testing it!
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 3/13/13 3:25 PM, Alex Rønne Petersen wrote:
> 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.

I agree. There's nothing to lose by giving it a cycle's shake.

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

On Wednesday, March 13, 2013 13:07:21 Walter Bright wrote:
> On 3/13/2013 12:32 PM, Brad Roberts wrote:
> > I fully agree with the "its too soon" sentiment.  There's a set of people that _really_ want it, and I think it's fairly safe to assume that they'll play and report issues.  No need to inflict the pain on everyone until SOME people have kicked the tires.  Reach out, engage with some people. Get SOME realish world testing done.
> 
> It ain't real unless the autotester is testing it!

Then I'm sure that builds could be set up which tested the shared library version.

But we stand a very high risk of breaking everybody's code if we switch to shared as the default without ironing it out first. While, I expect that we'll find the more obvious issues before we actually make a release, we may end up with more subtle issues which we don't detect immediately but still end up affecting a large portion of our user base.

Merely announcing that druntime itself supposed to work with the -shared flag now would result in a lot of people testing it, because a lot of people want that. Just look at how many people messed around with UDAs as soon as you announced them. If need be, we can create zip file marked as "experimental" so that people can mess around with it, and I fully expect that plenty of people will. But even just changing dmd.conf is going to break a lot of people's dmd installs, so lets not jump the gun on this.

By the way, why is the default dmd.conf not part of the dmd repo? As far as I can tell, it doesn't exist in source control at all, and that makes it _extremely_ easy for anyone using anything other than the official releases to miss updates to it.

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

Am 13.03.2013 20:25, schrieb Alex Rønne Petersen:
> 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.
>
When you say "explicitly ask for libdruntime.a" you mean by using the gcc/ld options "-Wl,-Bstatic////" and "-Wl,-Bdynamic//" right?

I'd say just ship the release with a libdruntime.so and libruntime.a and make sure dmd calls gcc like this:

"gcc -Wl,-Bstatic//-ldruntime -lphobos2 -Wl,-Bdynamic -lpthread -lm -lrt" This way we don't have to worry about passing the correct .a file to gcc, it should automatically detect the correct file.

For dynamic linking, just drop the "-Wl,-Bstatic" / "-Wl,-Bdynamic". Then add "|-static-libphobos -static-libdruntime|" flags to select between static and dynamic linking. Make  "|-static-libdruntime=true, ||-static-libphobos=true|" the default for one release, then in the next release change the defaults to false. Then linking with a static libdruntime would be as simple as passing "|-static-libdruntime|" to dmd. //

-- 
Johannes Pfau

On Wednesday, March 13, 2013 00:01:05 Walter Bright wrote:
> 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.

I'd like to point out that one place that we probably _won't_ want to use druntime as shared is dmd (once it's been ported to D), as I believe that doing so would mean that we'd have to recompile dmd after compiling druntime (as well as worry about making sure that dmd ran with the old copy of druntime until it had been compiled with the new one) - either that or dmd would have to have its own copy of the druntime shared lib (as the newly compiled druntime would not necessarily be compatible with the old one; this would be particularly bad on Windows due to how picky the dll linking scheme is in comparison to the so linking scheme). It would just be simpler for dmd to link against druntime statically.

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

On 03/13/2013 07:26 PM, Walter Bright wrote:
> 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? 
The idea was to keep on creating a druntime.a (with -fPIC) and combine it with phobos to a single phobos.so.

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

On 03/13/2013 08:13 PM, Walter Bright wrote:
> 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.
I actually had a look at that too some time ago, but it's not possible because most of the relocation information (and probably more) is gone.

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