DMD as cross-compiler
doob at me.com
Thu Nov 12 06:42:00 UTC 2020
On Wednesday, 11 November 2020 at 21:09:14 UTC, Robert M. Münch
> Digging into Go since some weeks, and the x-compiling of it is
> just super:
> GOOS=windows GOARCH=amd64 go build
> And you get a Windows EXE from OSX. That's it, zero config
> setup. The simpler these things work, the better for the whole
The reason why it works for Go is because they have their own
full toolchain. That means, their own compiler (including
backend), their own assembler, their own object format and their
own linker. All of these are written to be cross-target. In
addition to that, Go only interfaces with the kernel API. On
Linux, that means direct system calls, they're not even going
through the C wrappers. That's perfect for cross-compiling, since
there's nothing to link against.
They used to do this on macOS as well, but had to back down,
because on macOS the ABI is not the kernel, but the C wrappers
for the system calls.
Zig is doing something similar, they're actually doing one
better. Zig supports cross-compiling of C and C++ code as well (I
don't think Go does this). Zig ships with Clang and the C
standard library for various targets. But Zig uses their own
frontend but the LLVM backend and the LLD linker. They do seem to
have some trouble with linking some things on macOS. Also, on
macOS they're cheating. Because they cannot ship the SDK, they
solve the linking problem by allowing undefined symbols. I don't
know if Go does the same.
Unfortunately it won't be that simple for D. D took the easy way
out and relies both on the C standard library and other platform
specific libraries implemented in C. While it's easy to
cross-compile and object file, linking will not be as easy.
There's LLD, which works on Windows and Linux, but it doesn't
work for macOS. You also need the SDK to have something to link
with. Targeting Windows, it might be this easy, using LDC,
because it's already relying on LLD and the MinGW libraries.
More information about the Digitalmars-d