Update: a lot of this information is already outdated (good news!). See my latest update, and my second update.
Most high level languages are built as a layer on top of C. That includes out-of-the-box D, but it doesn’t
have to be that way: D is a plausible candidate for a “better C”. I think this is a pretty cool idea, so I’ve
been experimenting with it to see what’s possible. The dmd compiler (and very soon the ldc2
compiler) has a -betterC command line flag that’s
intended to remove dependencies on the D runtime. Unfortunately, it’s still extremely rudimentary — the docs only
promise it “omit[s] generating some runtime information and helper functions” — so in practice it’s hard
to write non-trivial D code without getting runtime dependencies, even if you don’t need them in theory.
With a little linker hacking, it’s possible to rip these unnecessary dependencies out of compiled D code. As
an example, I’ll completely remove all references to the D runtime out of some compiled D code so that it can
link directly to some C, as if it were C code to begin with.
I consider this an experimental hack until there’s more official compiler support. I just hope it helps more D
programmers experiment with the better C concept, so that we can develop an even better better C :)
Also, the D runtime appears in recurring flamewars about D, so I’ll have to say it: I think the runtime is
okay for most applications. It just might be necessary to remove it when doing certain types of systems
programming. Even then, there are useful compromises between the extremes of “no D runtime” and “full D
And if you’ve found this page after searching for a linker error you got compiling some normal D code, sorry,
this probably won’t be your solution. I recommend asking on the
Dlang forums instead.
Finally, I’m doing this with dmd, on a 64b GNU/Linux
system with PIC and stack canaries. Other systems will be similar because the D ABI is reasonably well specced
out (especially compared to C++’s ABI) but some things might still not be portable.
I’m ripping the runtime out hard, here, so I’ll lose a number of D features. PowerNex, a kernel written in D, ports a subset of the D runtime to
preserve some functionality, but I won’t do that at all, to get a kind of baseline.
GC is out, of course. This affects some features like dynamic array concatenation and closures.
D classes just won’t work without replacing at least some of object.d in the runtime library. That doesn’t bother me much
because I don’t rely on classes for programming. (Apparently C++ classes are an alternative.)
D’s runtime type information is based on TypeInfo
classes, so that has to go, too. If you’re doing a “better C” coding style, you’re probably not going to miss
that, either. Unfortunately, for legacy reasons, the runtime itself is a heavy user of TypeInfo, so the compiler will inject Typeinfo dependencies into code. For example, array comparison is
implemented using TypeInfo-based reflection, even when
the elements are plain old data and a simple memcmp is
enough. This isn’t hard to work around by removing the TypeInfo-based implementations and reimplementing things as needed,
but it’s a nuisance. Hopefully this situation should improve relatively quickly because there are performance
benefits even for code that isn’t -betterC.
Exceptions are classes and also use TypeInfo, so
they’re out. Even if you port enough object.d code to
support exceptions, the idiomatic usage of exceptions requires GC allocation. Auburn Sounds have documented a workaround.
Many D developers are already interested in implementing GC-less exceptions after fixes to @safe, scope and reference counting are finished.
Standard D assertions don’t work out of the box. On the other hand, they’re automatically removed from release
builds, so I’ve taken up the pattern of linking my test code to the D runtime and building my runtime-less code
I haven’t experimented with thread-local storage, but I’m okay with making all global data immutable or shared, anyway.
Initialisers (for modules and static data) that normally run before D’s main won’t run. I might have a try getting them to run sometime,
but for now they’re out. All data will need to be either purely constructed at compile time, or explicitly
constructed at runtime (or left with the default zeroed value).
The Phobos standard library is a bit tricky. Some of it usable, but a lot isn’t. Exceptions are a major
In case this all sounds too depressing, here are some things that we still have compared to C, even with 100%
of the D runtime removed:
A better, stronger type system. C’s type system has a few dark corners, especially around pointers and
arrays. C’s enumerated type values fill a global namespace and have no type safety.
Slices. These still work without GC (except for things like concatenation), and they’re a much less
error-prone way to handle chunks of memory than plain pointers.
Simple delegates. (It’s only full-featured closures that don’t work.)
Compile-time reflection and metaprogramming.
(Surprisingly) more low-level control without vendor-specific pragmas. (Standard D offers ways to specify
data alignment, for example.)
Doing the Surgery
Here’s some horrible, over-engineered sample code. It has one public function, count(), which returns a number that goes up by one every time it’s
called. That’s the only thing that’s extern(C);
everything else is used internally and is normal D. The unit test doesn’t work when linked to bare C, but there’s
nothing stopping us putting it in the code anyway and running it in a test build.
Here’s some simple C code that’ll use this awesome functionality to count to 10:
First, let’s compile the D code to an object file, and then try naïvely linking it with the C code:
Okay, that’s a bunch of errors from the linker trying to find things from the D runtime. The usual way to fix
this would be to do the compilation the other way around (compile C code to object files with gcc first, then let dmd put everything together and link in the D runtime). Of course,
I’m not going to do that because I don’t want the runtime. Let’s take a closer look at what linker symbols are
The symbols marked U are things that are missing and
need to be pulled in externally at link time. The global offset table is for PIC and is recognised by
gcc, and _Unwind_Resume is also recognised by gcc, but the other things are from the D runtime, and we need to
get rid of these dependencies. (Web search engines and the D runtime source code are good for identifying these
symbols. I also found this list of runtime functions recently,
too.) We can’t just remove the symbols, of course, we need to remove the things that depend on those
symbols — i.e., the relocations. Let’s take a look at them:
Each relocation record lists symbols needed for a section (a named chunk) of the binary object file.
So, _d_dso_registry that the linker complained about is
needed by the section .text.d_dso_init. It turns out
this section is for handling dynamic loading/unloading of D code, and making sure module constructors/destructors
are called. I can cut it out. Removing stuff is mostly safe because the linker will complain if we remove
something we depend on. I say “mostly” because removing static constructor code will obviously break things that
assume static constructors run on startup (the solution for now being to not assume that).
For completeness, here’s a list of all the sections:
The other sections I’ll get rid of are .eh_frame
(used for DWARF exception handling), minfo (D module
info), deh (some D-specific exception handling stuff),
.data.DW.ref.__dmd_personality_v0 (more DWARF exception
handling), the static constructors/destructors, and anything to do with TypeInfo and DSO. After that, I’ll also need to clean up some
That’s much better. Now we can use the compiled D code just like a compiled C object file: