[D-runtime] Time for druntime for Linux64 to default to a shared lib

[Alex Rønne Petersen]

On Wed, Mar 13, 2013 at 8:13 PM, Walter Bright <walter at 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 at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime