Which C runtime for MinGW and *BSD?

[Joakim via Digitalmars-d]

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.