Supporting musl libc

[Joakim via Digitalmars-d]

On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:
> As an alternative to glibc there's a C standard library called 
> musl [1]. This is the C standard library used by ELLCC [2], a 
> cross-compiler based on Clang. This cross-compiler makes it 
> very easy to target other platforms and can be used as the C 
> compiler when building with LDC.
>
> The issue is that musl doesn't support the functions defined by 
> execinfo.h: backtrace, backtrace_symbols_fd and 
> backtrace_symbols, since these are glibc extensions. As far as 
> I can see, these functions are used in two places in druntime: 
> src/rt/backtrace/dwarf.d [3] and src/core/runtime.d [4].
>
> The imports of execinfo is guarded by version(CRuntime_Glibc). 
> I see that CRuntime_Glibc is a predefined version identifier 
> defined by the compiler on Linux.
>
> I'm not sure how to best handle different C standard libraries 
> when it comes to choosing which one to use. Is it best to 
> choose that when building the compiler or when building 
> druntime? Or can it be a runtime option?
>
> [1] https://www.musl-libc.org
> [2] http://ellcc.org
> [3] 
> https://github.com/dlang/druntime/blob/master/src/rt/backtrace/dwarf.d#L41
> [4] 
> https://github.com/dlang/druntime/blob/master/src/core/runtime.d#L433-L434

It is a runtime option on Windows, when choosing between the 
Digital Mars C runtime and the MSVC runtime, which is why those 
are also predefined version identifiers.  The one for Glibc was 
added as an afterthought in that Windows PR, and Bionic was also 
reserved last fall, though my PR to actually define it has been 
in limbo for a year.  That's mostly my fault: I never got back to 
it when I focused on ldc and Android/ARM.

There was a lot of debate among the core team when even the 
Windows CRuntime support was finalized, with Walter wanting to 
minimize such predefined versions and some of the core team 
arguing against it even after it was merged.  Even the iOS 
predefined version took 5 months to get in, because there was 
debate whether Darwin should be allowed as a common version for 
all Apple platforms.

The reason I'm mentioning all this is that adding predefined 
versions is a matter of much debate, but that's how you'll likely 
implement it as a runtime option.  There is no good answer on 
this right now: I suggest you just implement it and worry about 
run-time versus compile-time when you're done.  Since you'll be 
doing the same work either way, ie adding or separating out a 
bunch of version blocks for musl in druntime, do it any way you 
like for now and you can worry about merging that last bit about 
compile-time vs runtime at the end.