www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Which C runtime for MinGW and *BSD?

reply Kai Nacke <kai redstar.de> writes:
Hi all!

I am trying to compile D code for MinGW and *BSD. Of course, I am 
using LDC.
The situation is a bit chaotic.

For MinGW, the compiler defines the versions Windows, Win32 and 
MinGW.
For *BSD, the compiler defines the *BSD version 
(FreeBSD/DragonFlyBSD/NetBSD/OpenBSD) and Posix.

If you try to compile druntime/Phobos:
- it compiles on FreeBSD :-)
- all other *BSD variants cause compile errors
- there are still some version(MinGW) sections in druntime but 
most of them moved to CRuntime_DigitalMars / CRuntime_Microsoft 
sections and are not available.

I like to clean this up. But what is the best way? Options are:

- create new sections for MinGW/DragonFlyBSD/NetBSD/OpenBSD and 
duplicate the definitions.
- define new C runtimes for MinGW (CRuntime_MinGW) and *BSD 
(CRuntime_libc).

MinGW/CRuntime_MinGW is a mix between the Windows and the GNU 
libraries. This requires some work.
CRuntime_libc could be used to consolidate the current code. As 
far as I know, BSD libc is also used by OS X and Solaris. This 
could reduce the amount of definitions.

Are there other solutions? What do you think?

Regards,
Kai
Oct 03 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 3 October 2015 at 15:02:24 UTC, Kai Nacke wrote:

 If you try to compile druntime/Phobos:
 - it compiles on FreeBSD :-)
 - all other *BSD variants cause compile errors


This is because only FreeBSD is actually defined everywhere.  The 
other BSDs are rarely mentioned, if at all.


 - there are still some version(MinGW) sections in druntime but 
 most of them moved to CRuntime_DigitalMars / CRuntime_Microsoft 
 sections and are not available.


I don't know anything about MinGW, but there was some discussion 
on how to handle it when CRuntime_Glibc was added late last year:

https://github.com/D-Programming-Language/dmd/pull/4111#issuecomment-66908355


 I like to clean this up. But what is the best way? Options are:

 - create new sections for MinGW/DragonFlyBSD/NetBSD/OpenBSD and 
 duplicate the definitions.
 - define new C runtimes for MinGW (CRuntime_MinGW) and *BSD 
 (CRuntime_libc).

 MinGW/CRuntime_MinGW is a mix between the Windows and the GNU 
 libraries. This requires some work.
 CRuntime_libc could be used to consolidate the current code. As 
 far as I know, BSD libc is also used by OS X and Solaris. This 
 could reduce the amount of definitions.


While they all have common ancestry from the original BSD libc 
out of Berkeley, they have all been forked and I doubt they have 
much in common nowadays.  The main reason we used different 
CRuntimes so far was because one kernel/OS used different libc's. 
  This is definitely true for the linux kernel, as almost all 
desktop and server linux uses glibc, while all mobile linux 
kernels use bionic.  Windows is a special case, because dmd comes 
with Walter's libc.  I don't think other OS's use different 
libc's much.

Of course, there's always an argument that it's easier to club 
together some libc's and that libc APIs should be separated from 
core OS APIs in general.  I don't know how true the first 
argument is, while the second may be a fair amount of work for 
not much gain.


 Are there other solutions? What do you think?


It would be really nice if we could automate all this, using 
Dstep as much as possible.  As for organizing by using one BSD 
libc, it all depends on how similar the libc's really are.  I 
doubt it'd help, but I don't know.
Oct 04 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, 4 October 2015 at 10:46:24 UTC, Joakim wrote:

 I don't think other OS's use different libc's much.


AFAIK, in the case of all of the *nixes other than Linux, libc is 
part of the OS itself (certainly, that's the case with the BSDs, 
Illumos, and Solaris), so the only way you'd have an alternate 
libc is for it to be a compatibility layer on top of the actual 
libc. So, in almost all cases, the OS and the libc stuff is 
inextricably tied. Similarly, the libc across those OSes is not 
shared, because it's part of the OS. So, while they're going to 
be very similar, each of the BSDs are going to need to have their 
libc's treated as different entities rather than being lumped 
together under the same version. Each one will have to be added 
to druntime on its own if we're going to support it.

- Jonathan M Davis
Oct 04 2015