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.
