Hacker News Reader

Comment by brabel | Hacker News Reader

Is it possible to do what Zig does and cross compile to any OS/arch, from any OS/arch?

Last I tried, I found some compiler options and commands to do it, but they were badly explained, I tried for hours and it just didn't work at all, so I gave up.

View on HN

The dmd D compiler can cross-compile to any of the targets that it supports. I use it all the time to develop on other platforms.

I am currently adding AArch64 support to DMD's code generator. dmd doesn't run on my Raspberry Pi (yet!), so I use sshfs to access the Pi's filesystem from Ubuntu, compile programs on Ubuntu, transfer the .o file to the Pi, link it on the Pi, and run it on the Pi.

I'm sorry you're having trouble with this, so I recommend posting on the D forums, and people are there to help!

https://forum.dlang.org/

The grandparent post refers to the fact that Zig ships with C, C++ library source that it lazily cross-builds (at least for linux, I don't recall how it solves this problem for macOS or windows). And possibly it uses lld too? Since Zig ships with these, it makes the whole cross-build experience much smoother and less dependent on whether your host OS distribution includes packages for your desired target OS/architecture.

Exactly. Zig tooling includes a linker, and that's also cross-platform. Zig can generate actual runnable executables that run anywhere from a single machine.

As far as I can tell, D's DMD can cross compile but not link. I probably missed that before (actually, I think I was trying with LDC, I found the page where they document the process while searching for it just now: https://wiki.dlang.org/Cross-compiling_with_LDC if you try those options, nothing works, at least from MacOS).

I just tried and this only works with the -c option (compile, but not link):

    dmd -os=linux -c source/app.d

Without `-c`:

``` Error: linker exited with status 1 cc app.o -o app -m64 -Xlinker -no_compact_unwind -L/Users/me/dlang/dmd-2.109.1/osx/bin/../lib -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm (dmd-2.109.1) ```

I am sure Walter knows how to compile on one machine, then go to another machine and do the linking or whatever is needed. I know nothing about those, but with Zig I need not know anything other than which flag to use to cross compile. It's a huge difference. D should do that, otherwise it's just not competitive for people like me (I am just an average joe programmer who knows how to write code but has very little interest in learning how linkers work).

> I am sure Walter knows how to compile on one machine, then go to another machine and do the linking or whatever is needed.

Historically, you would or at least could get your compiler and linker from different vendors -- assembler, disassembler and other tools too. So it's normal/common for C compilers like gcc, clang, dmd to not be distributed like Zig is.

But I would dare say that the way Zig is doing it is a great model for others.

> go to another machine and do the linking

BTW - if you use something like debian/ubuntu for development, they have compilers+linkers+binutils for several different architectures available to make cross-building without Zig at least a little bit easier.

FYI, Zig is in the process of dropping dependence on lld on Linux and Windows; macOS uses Zig's own linker since roughly 2021 as far as I recall. Tracking issue for reference: https://github.com/ziglang/zig/issues/8726

A cross-linker would be required for that to work. If you use a cross-linker with D, it should work.

Given Zig has one, it might actually be possible to delegate to that then?

It would be awesome to have a post explaining how to do that :)

The older “cross compiling Go with Zig” post might give a good start if you want to figure it out

I had a look at the post. It only shows how to tell the Go compiler how to use Zig as the C Compiler. In our case, what we need is to tell Zig to link the object files created by D.

I've had a look and saw that Zig is still implementing the `ld` command, but there's already a `ld.ldd` command which might work if you know what magical options to use. I've tried to link my D object file but it can't find a whole lot of generated symbols, and a quick search online does not tell me where do I get those symbols from. That's always what happens when I try to do stuff with D that's not well documented.

I tried this (used the dmd -v option to get the linker command):

    zig ld.lld -L/Users/me/dlang/dmd-2.109.1/osx/bin/../lib  app.o

Output:

```

ld.lld: error: undefined symbol: _d_assert_msg >>> referenced by myd/source/app.d >>> app.o:(_D4core8internal5newaa__T6makeAATAyaTiZQoFNaNeHQoiZSQByQBwQBq7AAShell) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format5write__T14formattedWriteTSQBm5stdio4File17LockingTextWriterTaTS3app__T9StringMapTiZQnZQDaFNfKQCqMxAaQBmZk) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format5write__T14formattedWriteTSQBm5stdio4File17LockingTextWriterTaTS3app__T9StringMapTiZQnZQDaFNfKQCqMxAaQBmZk) >>> referenced 27 more times

ld.lld: error: undefined symbol: _aaLen >>> referenced by myd/source/app.d >>> app.o:(_D4core8internal5newaa__T6makeAATAyaTiZQoFNaNeHQoiZSQByQBwQBq7AAShell) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format8internal5write__T15formatValueImplTSQBw5stdio4File17LockingTextWriterTHiHAyaiTaZQClFNfKQCaQuMKxSQEeQEd4spec__T10FormatSpecTaZQpZv) >>> referenced by myd/source/app.d >>> app.o:(_D3std6format8internal5write__T15formatValueImplTSQBw5stdio4File17LockingTextWriterTHAyaiTaZQCjFNfKQByQsMKxSQEcQEb4spec__T10FormatSpecTaZQpZv)

ld.lld: error: too many errors emitted, stopping now (use --error-limit=0 to see all errors)

```

Do you know how to get past that?

Looks like the D runtime library isn't being linked in.

I have to confess to mostly just lurking Zig with interest, but not _actually_ knowing what I'm talking about. I do know their linker game has improved a _lot_ since that old Go article, so it's quite likely that Zig can do what you want. You might want to try their IRC or Discord.

Generally, the hard part isn't the cross compiler (nor, these days, the cross binutils), but the cross libraries. There are at least 3 ways (/usr/lib/$ARCH, /usr/$ARCH/lib, /$CHROOT/usr/lib/) to set up the libraries, all incompatible with each other.

Zig is notable for putting a lot of work into hard-coding basic C libraries, though of course you still need a scattering of other C libraries for most real-world programs.

(for a sufficiently advanced language ecosystem, the language's own libraries should be easy enough)

The nixpkgs have a rather elegant way to deal with that. Let's presume you need a libpng for an armv7 platform, such as an old RaspberryPi. Then Nix allows you to

- get a suitable cross compiler toolchain

- pick whether you want dynamic or static linking (most likely static when the target system does not come with /nix/store)

- compile all prerequisites for the library such as transitive dependencies

- compile the library with the cross compiler for the selected target arch

All in one command line call, that does not require you to 'apt-get install' any of the tools manually:

  nix-build '<nixpkgs>' -A pkgsStatic.libpng --arg crossSystem '{ config = "armv7a-unknown-linux-gnueabihf"; }'

You can combine zig and nix with <https://github.com/Cloudef/zig2nix> (shameless plug)

Reply on news.ycombinator.com