Supporting musl libc

Chad Joan via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 12 21:28:09 PDT 2017


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]. [...]
>
> 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 just ran into these problems while trying to get D running on a 
hardened Gentoo system using musl libc.

Using a patched gdc-4.9.4 I've been able to compile and run a 
simple D "Hello world".  That made me very happy!

Here are the binaries:
http://www.chadjoan.com/d/gdc-4.9.4-hardened-musl.tar.gz

I have forked the dlang overlay in the hope that it can provide 
the necessary information if someone tries to compile the thing 
for themselves:
https://github.com/chadjoan/dlang

This is pretty recent work, so I haven't had time to use it for 
anything besides "Hello world".  I'm also not sure how to run 
regression tests for this thing, if there even are any.  So this 
is all very untested.  I'm sharing a minimally useful milestone, 
and hopefully it is more than that.

Background:

Earlier, I modified the "dmd-2.067.1-r2" ebuild from the dlang 
overlay and actually managed to get it to compile and emit 
executables.  The BSD execinfo did not even manage to run its own 
test program on my system without segfaulting.  So I used 
libbacktrace for backtraces and had to do a bunch of other 
patching to get dmd/druntime/phobos to build on this system; it 
involved a lot of trial-and-error.  Although it emitted 
executables, these executables would segfault or overstep 
security bounds enforced by the kernel (to the point where 
removing all PAX restrictions would not help it).  I remember 
something about text relocations, but at this point it's been a 
while, so my memory of details is lacking.  Diving into codegen 
is far too time-consuming in my situation, so that was a dead-end.

I started over with gdc, because I knew that gcc could already 
generate working executables on the system.  Most of the pain in 
this process involved two things: (1) coercing portage into 
building gdc in its own directory so that it didn't take over my 
system compiler and (2) fixing gcc/gdc build scripts.  It was 
important to use portage and not just manually configure gdc, 
because I wanted to ensure that the resulting gdc build would be 
configured and patched in a way closely matching what my system 
compiler does (and thus having higher success chances).  Trying 
to configure and patch it by hand, thus repeating a lot of hard 
work already done by Gentoo maintainers, is... not practical.  As 
for the build scripts: I have no idea what conventions gcc 
maintainers use for these things, and thus how I might do basic 
things like use an environment variable from outside of the build 
process to affect what flags are passed to a compiler.  There be 
hacks in my patching!  As an example, it will unconditionally 
compile the D frontend with -fPIC; if you end up building this on 
another system and you didn't want that, then it's just too bad 
;)  So it took more trial-and-error, and maybe a little 
compromise, but eventually it got there.

I hope this helps someone.


More information about the Digitalmars-d mailing list