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

-- 
/Jacob Carlborg

On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:
> 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?

Shouldn't be runtime detected, but a linktime/compile option.
We introduced CRuntime_Glibc specifically to separate libc from kernel differences, e.g. to support android.
Have a look at how -mscoff32 and Android are implememted in dmd.
At best defining CRuntime_Glibc should move into dmd.conf, where you could also select a different phobos library to link.

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.

On Tuesday, 17 May 2016 at 09:26:33 UTC, Martin Nowak wrote:
> On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:
>> 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?
>
> Shouldn't be runtime detected, but a linktime/compile option.

Jacob, when you said "runtime option," you meant when running the compiler, right?  That's how I took it: the C library is chosen either when building the compiler or running the compiler.  On Windows, it's when running the compiler.

> We introduced CRuntime_Glibc specifically to separate libc from kernel differences, e.g. to support android.
> Have a look at how -mscoff32 and Android are implememted in dmd.

Android is not in dmd yet, as I mentioned, you can look at my small PR though:

https://github.com/dlang/dmd/pull/3643

> At best defining CRuntime_Glibc should move into dmd.conf, where you could also select a different phobos library to link.

Man, I'm not looking forward to that debate, though I'm not sure I care that much about its outcome myself. ;)

On 2016-05-17 11:26, Martin Nowak wrote:

> Shouldn't be runtime detected, but a linktime/compile option.
> We introduced CRuntime_Glibc specifically to separate libc from kernel
> differences, e.g. to support android.
> Have a look at how -mscoff32 and Android are implememted in dmd.
> At best defining CRuntime_Glibc should move into dmd.conf, where you
> could also select a different phobos library to link.

In this case when I said "runtime", I meant runtime for the compiler. -mscoff32 is a different object format that just happens to use a different C runtime as well. But I guess we could add a new flag, -cruntime=musl or something.

-- 
/Jacob Carlborg

On 2016-05-17 11:32, Joakim wrote:

> Jacob, when you said "runtime option," you meant when running the
> compiler, right?

Exactly.

> That's how I took it: the C library is chosen either
> when building the compiler or running the compiler.  On Windows, it's
> when running the compiler.
>
>> We introduced CRuntime_Glibc specifically to separate libc from kernel
>> differences, e.g. to support android.
>> Have a look at how -mscoff32 and Android are implememted in dmd.
>
> Android is not in dmd yet, as I mentioned, you can look at my small PR
> though:
>
> https://github.com/dlang/dmd/pull/3643

Looks like a "runtime" option. It's not hard to implement, just a question of which approach we would like to use.

-- 
/Jacob Carlborg

On 2016-05-17 11:27, Joakim wrote:

> 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.

It depends. One approach would be to add an option to the druntime makefile, which would add -version CRuntime_Musl when compiling. In that case version(CRuntime_Musl) needs to come before version(CRuntime_Glibc) when declaring the imports. It doesn't sound like a good idea, to depend on the order of the version statements, but it's still a possibility.

-- 
/Jacob Carlborg

On Tuesday, 17 May 2016 at 08:51:01 UTC, Jacob Carlborg wrote:
>
> 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.

It's worth noting that musl does support a lot of GNU-isms, but the debug stuff is probably not on the table.  Here's some background on that from Rich Felker himself:

http://www.openwall.com/lists/musl/2015/04/09/3

-Wyatt

On 2016-05-17 15:42, Wyatt wrote:

> It's worth noting that musl does support a lot of GNU-isms, but the
> debug stuff is probably not on the table.  Here's some background on
> that from Rich Felker himself:
>
> http://www.openwall.com/lists/musl/2015/04/09/3

Yeah, I saw that post.

-- 
/Jacob Carlborg

On Tuesday, 17 May 2016 at 11:30:33 UTC, Jacob Carlborg wrote:
> On 2016-05-17 11:27, Joakim wrote:
>
>> [...]
>
> It depends. One approach would be to add an option to the druntime makefile, which would add -version CRuntime_Musl when compiling. In that case version(CRuntime_Musl) needs to come before version(CRuntime_Glibc) when declaring the imports. It doesn't sound like a good idea, to depend on the order of the version statements, but it's still a possibility.

I wouldn't take the existence of CRuntime_Glibc as etched in stone, but whatever happens, they will not both be defined at the same time, so I don't think you should worry about the order.  You can modify dmd to replace Glibc with Musl for now, and worry about how it'll be defined officially later.