On Tuesday, 12 April 2016 at 07:03:44 UTC, Russel Winder wrote:

If the Debian ldc2 compiler is crashing on the same source that gdc compiles that sounds like a packaging problem. Or use of outdated D? ldc is generally much more up to date that gdc so shouldn't the order be ldc | gdc | d-compiler?

I didn't get it to compile properly with LDC, which might of course have been due to the outdated LDC version in Debian and Ubuntu at that time. Also, GDC is available for more architectures and wasn't stuck in unstable at the time dub was packaged.

On Debian Sid ldc2 is 2.068.2 and gdc doesn't advertise which version of D it is.

Should be D2, there doesn't seem to be much D1 code around anymore...

I assume that the DMD package from dlang, or better d-apt, sets the d- compiler property. Should dmd be prefered if it is present?

I think so, since when installing it from non-free 3rd-party sources, the user made an explicit choice for DMD. In terms of packaging, the packaging doesn't really care, any D compiler will satisfy the requirements of the dub package.

> And has dub's config been tweaked accordingly in terms of > which compiler it prefers to use ... ? I didn't touch that, since dub seems to automatically find the right compiler. The preference seems to be dmd >> gdc >> ldc2, which looks sane to me.

Sane, yes, but dmd → ldc2 → gdc is probably a better choice simply because ldc tends to be more up to date than gdc – this is not a maintainer problem just a release flow problem.

I can't comment on that... In any case, users and packagers can choose whatever D compiler they prefer, there is no "enforcement" of any kind happening (just default choices).

It's really bad that GDC isn't part of the official GCC yet, and the standard libraries differ so much between the compilers (mainly due to phobos progressing very quickly).

GDC is definitely ipart of the GCC thanks to Iain's ongoing efforts, with support from others. GDC would not be in the Debian repository if it wasn't part of GCC.

That's unfortunately not the case. If you download gcc-5_5.3.1.orig.tar.gz from https://packages.debian.org/source/sid/gcc-5 , you can see that GDC was manually inserted. I think the problem might lie in the GDC frontend code not being subjected to the FSF CLA, but that's just a guess - Iain likely knows more :)

The problem here is that the Fedora GCC packagers package GCC-Go but do not package GDC. This means GDC is not present in any of Fedora, CentOS, RHEL, Scientific Linux.

The last on this list is more important than you might think.

Coming from a scientific background, I am with you on this... Problem again is that gccgo is part of GCC, so you just need to enable it, while gdc is out-of-tree.

Also the ldc package in Rawhide is only 0.16.1 which is really rather ancient.

Jup - to be honest, I think the state of the free compilers in Linux distributions is really something which is limiting D the most at time. New programming languages like Rust have it much easier in that regard.

For Debian Stretch I assume the situation will be much better
though :-) (given the state of the LDC and GDC Git repos).

I think the policy simply has to be to make sure that LDC and GDC are as up to date as possible in Sid ­– which already happens

Jup - ideally, the Debian D team would give some advice on default compilers and versions. But that team seems to be dead.

– and in Fedora Rawhide – which no-one but me seems to think is important.

Ideally find a Fedora developer (who ideally also works on RHEL) and convince him. The easiest way to get the compiler in would be a killer application written in D which requires an up-to-date toolchain. E.g. Docker is written in Go, many people want Docker, so Go is up-to-date (that's over-simplified, but it generally works that way...).


Reply via email to