www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Cross-compiling a static binary from GitHub Actions

reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
Hi,

The problem: I made a tool written in D, but some people are 
having trouble building/running it on non-x86_64 architectures 
across various distributions. (I managed to build a static binary 
for x86_64.)

My goal: build a static binary of a D program for Linux-AArch64 
from GitHub Actions (as an artifact).

Does anyone have any advice in this direction?

I found https://wiki.dlang.org/Cross-compiling_with_LDC , which 
is a good resource, but leaves open the question for how better 
to set up the toolchain, dependency pinning, as well as obtaining 
/ building the static libraries for C dependencies (such as 
glibc).

Maybe someone has a Dockerfile on Nix script which demonstrates 
cross-compiling static binaries of D programs?

Thanks!
Sep 25 2021
next sibling parent reply kinke <noone nowhere.com> writes:
On Saturday, 25 September 2021 at 07:59:08 UTC, Vladimir 
Panteleev wrote:

 (I managed to build a static binary for x86_64.)


Linked statically against glibc? I thought that's not really 
possible, and one would need to resort to another libc like musl 
for fully statically linked binaries. Could you link to the repo 
of the tool?

That said, linking dynamically against a rather old glibc seems 
to work in many cases. The official LDC binaries do that and are 
built on Ubuntu 18.04 for that reason; they seem to work on most 
distros, excl. musl-only Alpine. So I'd expect cross-compiling on 
Ubuntu 18 and using its cross-gcc toolchain to work for most 
people.

Another (potentially more flexible) option could be using Travis 
for native AArch64 compilation - again, that's what LDC does 
(https://github.com/ldc-developers/ldc/blob/master/.travis.yml). 
They have a Ubuntu 18.04 image, and the D integration still 
works, on AArch64 too. Their AArch64 service is sponsored by ARM 
and doesn't cost any credits for public open-source projects.
Sep 25 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 25 September 2021 at 16:12:52 UTC, kinke wrote:

 On Saturday, 25 September 2021 at 07:59:08 UTC, Vladimir 
 Panteleev wrote:

 (I managed to build a static binary for x86_64.)


 Linked statically against glibc? I thought that's not really 
 possible, and one would need to resort to another libc like 
 musl for fully statically linked binaries. Could you link to 
 the repo of the tool?


Sure:

https://github.com/CyberShadow/btdu

And here is the script I use to link the x86_64 binary:

https://gist.github.com/CyberShadow/df49946888ad1ea683729f57c5e59d8a

During linking I see warnings such as:

     warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the 
glibc version used for linking

but I haven't paid them mind because the application is not using 
networking (or at least name resolution).

ldd says "not a dynamic executable", so I guess that makes it 
fully static?


 That said, linking dynamically against a rather old glibc seems 
 to work in many cases. The official LDC binaries do that and 
 are built on Ubuntu 18.04 for that reason; they seem to work on 
 most distros, excl. musl-only Alpine. So I'd expect 
 cross-compiling on Ubuntu 18 and using its cross-gcc toolchain 
 to work for most people.


My understanding is that you can't really pick-and-choose which 
libraries you want to link statically vs. dynamically (or at 
least, the toolchain didn't let me). I also depend on libncurses, 
which has broken its ABI in the past, so I would like to avoid 
that dependency if possible for the stand-alone binary.


 Another (potentially more flexible) option could be using 
 Travis for native AArch64 compilation - again, that's what LDC 
 does 
 (https://github.com/ldc-developers/ldc/blob/master/.travis.yml). They have a
Ubuntu 18.04 image, and the D integration still works, on AArch64 too. Their
AArch64 service is sponsored by ARM and doesn't cost any credits for public
open-source projects.


That's interesting, thanks - though I'm not sure why it would be 
considered more flexible, as it would create a rather strong 
dependency on a third-party service with a tumultuous track 
record :)
Sep 25 2021
parent reply kinke <noone nowhere.com> writes:
On Saturday, 25 September 2021 at 16:23:09 UTC, Vladimir 
Panteleev wrote:

 That's interesting, thanks - though I'm not sure why it would 
 be considered more flexible, as it would create a rather strong 
 dependency on a third-party service with a tumultuous track 
 record :)


Flexible as in being able to run any unittests, install a native 
musl toolchain etc., plus I'd expect stuff like 
`-L-l:libtermcap.a` to work there as well (i.e., static libs 
being available just like on an x64 image).
Sep 25 2021
next sibling parent reply kinke <noone nowhere.com> writes:
On Saturday, 25 September 2021 at 16:28:16 UTC, kinke wrote:

 plus I'd expect stuff like `-L-l:libtermcap.a` to work there as 
 well (i.e., static libs being available just like on an x64 
 image).


According to 
https://packages.ubuntu.com/bionic/arm64/libtinfo-dev/filelist, 
the static libs are probably generally available. So something 
like
```
dpkg --add-architecture arm64
apt-get update
apt-get install libtinfo-dev:arm64
```
might be sufficient to make them available for the 
gcc-aarch64-linux-gnu toolchain as well.
Sep 25 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 25 September 2021 at 16:35:33 UTC, kinke wrote:

 According to 
 https://packages.ubuntu.com/bionic/arm64/libtinfo-dev/filelist, 
 the static libs are probably generally available. So something 
 like
 ```
 dpkg --add-architecture arm64
 apt-get update
 apt-get install libtinfo-dev:arm64
 ```
 might be sufficient to make them available for the 
 gcc-aarch64-linux-gnu toolchain as well.


That looked promising so I tried it out.

Ubuntu seems to require some non-trivial edits to 
/etc/apt/sources.list in order to add arm64, so I proceeded with 
Debian.

On Bullseye, I got linking errors with undefined references to 
'deflateInit2_', and no matter how I tried to add libz they 
wouldn't go away, so I proceeded with Buster.

The Dub version packaged in Buster is too old and doesn't work 
any more, so I used the installation script from the website to 
install ldc+dub.

This gets me to a point where I can build the x86_64 binary. But, 
if I try "-mtriple arm64-linux-gnu", I get "/usr/bin/ld.gold: 
fatal error: btdu-static-arm64.o: unsupported ELF machine number 
183". Not sure how to proceed from here, fiddled with --linker 
but couldn't get anything to work.

Say, shouldn't it be using lld anyway? I tried installing lld, 
but that didn't work because it didn't match the LLVM version in 
ldc.

Here is what I have:
https://github.com/CyberShadow/btdu/tree/next/release
Sep 25 2021
parent reply kinke <noone nowhere.com> writes:
On Saturday, 25 September 2021 at 18:08:44 UTC, Vladimir 
Panteleev wrote:

 This gets me to a point where I can build the x86_64 binary. 
 But, if I try "-mtriple arm64-linux-gnu", I get 
 "/usr/bin/ld.gold: fatal error: btdu-static-arm64.o: 
 unsupported ELF machine number 183". Not sure how to proceed 
 from here, fiddled with --linker but couldn't get anything to 
 work.


I assume you've skipped the 
https://wiki.dlang.org/Cross-compiling_with_LDC#Tweaking_the_LD
_configuration_file part and expect passing -mtriple to be sufficient for
linking as well. In that case, read that section again - you'll need to pass
`-gcc=aarch64-linux-gnu-gcc` for LDC to invoke the cross-gcc as linker driver.
*And* specify the AArch64 druntime/Phobos dir via `-L` (but the linker might
still complain about the x64 libs dir specified in the default ldc2.conf
section). [`ldc2 -v` shows the linker cmdline for troubleshooting.]
Sep 25 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 25 September 2021 at 20:12:09 UTC, kinke wrote:

 I assume you've skipped the 
 https://wiki.dlang.org/Cross-compiling_with_LDC#Tweaking_the_LD
_configuration_file part and expect passing -mtriple to be sufficient for
linking as well. In that case, read that section again - you'll need to pass
`-gcc=aarch64-linux-gnu-gcc` for LDC to invoke the cross-gcc as linker driver.
*And* specify the AArch64 druntime/Phobos dir via `-L` (but the linker might
still complain about the x64 libs dir specified in the default ldc2.conf
section). [`ldc2 -v` shows the linker cmdline for troubleshooting.]


I can't get `-gcc` to do anything, it always invokes 
`/usr/bin/cc`.

Example with `-v`:

```
/usr/bin/cc btdu-static-aarch64.o -o btdu-static-aarch64 
-fuse-ld=gold -Lrelease -l:libtermcap.a -l:libncursesw.a 
-l:libtinfo.a -l:libz.a 
-L/root/dlang/ldc-1.27.1/bin/../lib-aarch64 -lphobos2-ldc 
-ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm
```

Whether it's specified in the configuration file or on the 
command line doesn't stop it from running `/usr/bin/cc`.

(I didn't configure the library stuff yet)
Sep 26 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 26 September 2021 at 07:51:01 UTC, Vladimir Panteleev 
wrote:

 I can't get `-gcc` to do anything, it always invokes 
 `/usr/bin/cc`.


Got it, I forgot to install that package, and LDC is silently 
ignoring the value if it can't find it:

https://github.com/ldc-developers/ldc/blob/58ee56a2100eb301c55220933dd2a84d3a7d2843/driver/tool.cpp#L59-L62
Sep 26 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 26 September 2021 at 07:57:33 UTC, Vladimir Panteleev 
wrote:

 [snip]


It works!

https://github.com/CyberShadow/btdu/runs/3712470882

Thank you!
Sep 26 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 26 September 2021 at 12:31:12 UTC, Vladimir Panteleev 
wrote:

 On Sunday, 26 September 2021 at 07:57:33 UTC, Vladimir 
 Panteleev wrote:

 [snip]


 It works!

 https://github.com/CyberShadow/btdu/runs/3712470882

 Thank you!


Well, the build works, but the built program doesn't work. 
Exceptions cause an abort and I think the process creation 
problem is still there. Same thing both on my phone and on the 
qemu docker thing. Maybe because of some difference because it's 
not the same ARM variant or something?

Oh well, I'll have to leave this for another day.

I filed a bug against libphobos2-ldc-shared-dev in Debian because 
you can't install multiarch versions side by side for cross 
compiling, maybe if that's fixed then this will become a bit 
easier.
Sep 26 2021
parent reply kinke <noone nowhere.com> writes:
On Sunday, 26 September 2021 at 13:17:56 UTC, Vladimir Panteleev 
wrote:

 Well, the build works, but the built program doesn't work. 
 Exceptions cause an abort and I think the process creation 
 problem is still there. Same thing both on my phone and on the 
 qemu docker thing. Maybe because of some difference because 
 it's not the same ARM variant or something?


Hmm, no idea - this basic stuff works for Travis on Ubuntu 18.04, 
incl. a fully green dmd-testsuite, green std.process unittests, 
and using the native dub build to build reggae. There are still 
some failing library unittests on AArch64, like a hanging 
core.thread and some Phobos modules (mostly wrt. incomplete 
support for 128-bit quad-precision `real` AFAICT), but exceptions 
and process creation work just fine there. Same reports for 
Android AArch64. Maybe give it one more shot without `-static` 
just to see if that changes things?
Sep 26 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 26 September 2021 at 17:31:35 UTC, kinke wrote:

 On Sunday, 26 September 2021 at 13:17:56 UTC, Vladimir 
 Panteleev wrote:

 Well, the build works, but the built program doesn't work. 
 Exceptions cause an abort and I think the process creation 
 problem is still there. Same thing both on my phone and on the 
 qemu docker thing. Maybe because of some difference because 
 it's not the same ARM variant or something?


 Hmm, no idea - this basic stuff works for Travis on Ubuntu 
 18.04, incl. a fully green dmd-testsuite, green std.process 
 unittests, and using the native dub build to build reggae.


Maybe that's because you have the exactly correct kind of ARM 
there?

Here's a full reproducer for the segfault issue:

```
$ docker run --rm -ti arm64v8/ubuntu
```

and in the container:

```
apt-get update
apt-get install -y gcc curl xz-utils libxml2
curl -LfO 
https://github.com/ldc-developers/ldc/releases/download/v1.27.1/ldc2-1.27.1-linux-aarch64.tar.xz
tar Jxf ldc2-1.27.1-linux-aarch64.tar.xz
echo 'import std.stdio, std.process; void main() { 
writeln(spawnProcess(["/bin/true"]).wait()); }' > test.d
ldc2-1.27.1-linux-aarch64/bin/ldc2 -run test.d
```


 Maybe give it one more shot without `-static` just to see if 
 that changes things?


I tried a non-static build on my phone, but that wants 
`/lib/ld-linux-aarch64.so.1`, but the Linux userspace I have only 
has `/lib/ld-linux-armhf.so.3`. Apparently `size_t` is 32-bit on 
`armhf`. However, the statically linked `aarch64` binary does run 
- up until an exception is thrown.
Sep 26 2021
parent reply kinke <noone nowhere.com> writes:
On Sunday, 26 September 2021 at 20:00:15 UTC, Vladimir Panteleev 
wrote:

 Maybe that's because you have the exactly correct kind of ARM 
 there?


My (rough and superficial) understanding is that AArch64 is 
nowhere near as fragmented as the old ARM32 ISA families (with 
optional FP & SIMD units, soft-float/hard-float/softFP ABI 
variations etc. etc.), and that LDC/LLVM default to the v8 
baseline ISA. We've used Shippable CI before, which used a 
different CPU than Travis now (obviously no Smartphone chips). 
And the last time I worked on AArch64 about a year ago or so was 
in a qemu VM (FWIW, on a Windows host - working just fine!), 
using some Debian image IIRC - without any problems of this kind.


 Here's a full reproducer for the segfault issue:


Thx, but it doesn't catch my interest - no docker on my machine, 
plus the qemu AArch64 VM is on a different box. I haven't heard 
of any other reports of this kind, and as there are AArch64 
distro packages of LDC (incl. Android packages which I know are 
used by some people), I guess I would have heard if such basic 
failures were wide-spread.
Sep 26 2021
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 27 September 2021 at 02:27:32 UTC, kinke wrote:

 Thx, but it doesn't catch my interest


No worries, I'll dig into this myself a bit more if I get more 
requests/complaints from tool users. Thanks!
Sep 26 2021
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 27 September 2021 at 02:27:32 UTC, kinke wrote:

 Thx, but it doesn't catch my interest - no docker on my 
 machine, plus the qemu AArch64 VM is on a different box. I 
 haven't heard of any other reports of this kind, and as there 
 are AArch64 distro packages of LDC (incl. Android packages 
 which I know are used by some people), I guess I would have 
 heard if such basic failures were wide-spread.


Rented an AWS EC2 ARM box today and tried it out there. The 
std.process segfaults indeed appear to be specific to the 
QEMU/binfmt interaction, however, exceptions still did not work. 
I narrowed it down to `-static`, confirming your guess. Seems to 
be an issue with unwinding?

```



btdu-static-aarch64`uw_init_context_1 + 580

btdu-static-aarch64`_Unwind_Backtrace + 84

68

btdu-static-aarch64`_D4core7runtime19defaultTraceHandlerFPvZC6object
Throwable9TraceInfo + 116

btdu-static-aarch64`_d_createTrace + 76

btdu-static-aarch64`_d_throw_exception + 176

btdu-static-aarch64`_D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyam
AxaZNn(file=(length = 39, ptr = u8"/home/ubuntu/btdu/source/btdu/subproc.d"),
line=109, msg=(length = 33, ptr = u8"Unexpected subprocess termination")) at
exception.d:517:9
```

To reproduce:

```console
$ echo 'import std.stdio, std.process; void main() { 
writeln(spawnProcess(["/bin/true"]).wait()); }' > test.d
$ ldc2-1.27.1-linux-aarch64/bin/ldc2 -static test.d
$ ./test
Aborted (core dumped)
```

Worth upgrading this to an issue?

Also, any ideas for workarounds? (Non-static builds lose most 
benefits of distributing pre-built binaries in the first place.)

Thanks!
Oct 01 2021
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 1 October 2021 at 11:18:52 UTC, Vladimir Panteleev 
wrote:

 To reproduce:


Sorry, wrong code, should be:


 ```console
 $ echo 'import std.stdio; void main() { try throw new 
 Exception("Caught"); catch (Exception e) writeln(e); }' > test.d
 ```
Oct 01 2021
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
On Friday, 1 October 2021 at 11:18:52 UTC, Vladimir Panteleev 
wrote:

 Rented an AWS EC2 ARM box today and tried it out there. The 
 std.process segfaults indeed appear to be specific to the 
 QEMU/binfmt interaction, however, exceptions still did not 
 work. I narrowed it down to `-static`, confirming your guess. 
 Seems to be an issue with unwinding?

 ```

 224


 btdu-static-aarch64`uw_init_context_1 + 580

 btdu-static-aarch64`_Unwind_Backtrace + 84

 + 68

 btdu-static-aarch64`_D4core7runtime19defaultTraceHandlerFPvZC6object
Throwable9TraceInfo + 116

 btdu-static-aarch64`_d_createTrace + 76

 btdu-static-aarch64`_d_throw_exception + 176

 btdu-static-aarch64`_D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyam
AxaZNn(file=(length = 39, ptr = u8"/home/ubuntu/btdu/source/btdu/subproc.d"),
line=109, msg=(length = 33, ptr = u8"Unexpected subprocess termination")) at
exception.d:517:9
 ```


Hmm, apparently coming from libbacktrace. IIRC, EH and backtrace 
code in druntime for Linux AArch64 doesn't really diverge from 
x64.

I guess you *could* try compiling druntime manually, defining 
`version (DRuntime_Use_Libunwind)` to use libunwind instead of 
libbacktrace. See 
https://wiki.dlang.org/Building_LDC_runtime_libraries for how to 
do that quite painlessly.
Oct 01 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 1 October 2021 at 11:41:06 UTC, kinke wrote:

 I guess you *could* try compiling druntime manually, defining 
 `version (DRuntime_Use_Libunwind)` to use libunwind instead of 
 libbacktrace. See 
 https://wiki.dlang.org/Building_LDC_runtime_libraries for how 
 to do that quite painlessly.


Wow, that looks cool.

`version=DRuntime_Use_Libunwind` seems to have bitrotten a bit 
though I think:

```
core/internal/backtrace/handler.d(89): Error: undefined 
identifier `Dl_info`
core/internal/backtrace/handler.d(90): Error: undefined 
identifier `dladdr`
```
Oct 01 2021
parent reply kinke <noone nowhere.com> writes:
On Friday, 1 October 2021 at 11:46:37 UTC, Vladimir Panteleev 
wrote:

 `version=DRuntime_Use_Libunwind` seems to have bitrotten a bit 
 though I think:


Argh, yeah, it's currently only enabled by default for musl, and 
that isn't CI-tested, going the usual way... ;) - Probably needs 
to be fixed in upstream druntime.
Oct 01 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 1 October 2021 at 11:49:20 UTC, kinke wrote:

 On Friday, 1 October 2021 at 11:46:37 UTC, Vladimir Panteleev 
 wrote:

 `version=DRuntime_Use_Libunwind` seems to have bitrotten a bit 
 though I think:


 Argh, yeah, it's currently only enabled by default for musl, 
 and that isn't CI-tested, going the usual way... ;) - Probably 
 needs to be fixed in upstream druntime.


I think there's more. I added the import and the runtime built, 
however, the application now fails to link because it can't find 
`unw_getcontext` etc. However, looking in `/usr/include`, I see:

```c
#define unw_getcontext(uc)              unw_tdep_getcontext(uc)
```

This include file is in `/usr/include/aarch64-linux-gnu`, which I 
guess might mean that the libunwind ABI interface differs across 
architectures :(
Oct 01 2021
parent kinke <noone nowhere.com> writes:
On Friday, 1 October 2021 at 11:57:53 UTC, Vladimir Panteleev 
wrote:

 I think there's more. I added the import and the runtime built, 
 however, the application now fails to link because it can't 
 find `unw_getcontext` etc. However, looking in `/usr/include`, 
 I see:

 ```c
 #define unw_getcontext(uc)              unw_tdep_getcontext(uc)
 ```

 This include file is in `/usr/include/aarch64-linux-gnu`, which 
 I guess might mean that the libunwind ABI interface differs 
 across architectures :(


Argh... and that might be yet another macro, and possibly even 
buggy if not from a pretty recent libunwind version: 
https://github.com/libunwind/libunwind/pull/221/files

[For 32-bit ARM, we have this to account for libunwind macro 
trouble: 
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/arm_unwind.c]
Oct 01 2021
prev sibling parent reply kinke <noone nowhere.com> writes:
On Friday, 1 October 2021 at 11:18:52 UTC, Vladimir Panteleev 
wrote:

 Also, any ideas for workarounds? (Non-static builds lose most 
 benefits of distributing pre-built binaries in the first place.)


I guess going down the rabbit hole all the way isn't really what 
you're looking for. ;) - I'd probably settle for dynamically 
linking against an old glibc, and only linking the other libs 
statically. Won't work on your phone, but I guess btrfs isn't 
really a thing on phones. :]
Oct 01 2021
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Friday, 1 October 2021 at 13:20:57 UTC, kinke wrote:

 I guess going down the rabbit hole all the way isn't really 
 what you're looking for. ;) - I'd probably settle for 
 dynamically linking against an old glibc, and only linking the 
 other libs statically. Won't work on your phone, but I guess 
 btrfs isn't really a thing on phones. :]


That works, thank you!
Oct 01 2021
prev sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 25 September 2021 at 16:28:16 UTC, kinke wrote:

 On Saturday, 25 September 2021 at 16:23:09 UTC, Vladimir 
 Panteleev wrote:

 That's interesting, thanks - though I'm not sure why it would 
 be considered more flexible, as it would create a rather 
 strong dependency on a third-party service with a tumultuous 
 track record :)


 Flexible as in being able to run any unittests, install a 
 native musl toolchain etc., plus I'd expect stuff like 
 `-L-l:libtermcap.a` to work there as well (i.e., static libs 
 being available just like on an x64 image).


Got it. I guess some qemu-based setup would achieve the same 
thing (with a LOT more fiddling up front).

Speaking of, I found this crazy wizardry which looks quite 
interesting:

https://github.com/multiarch/qemu-user-static
Sep 25 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Saturday, 25 September 2021 at 18:31:27 UTC, Vladimir 
Panteleev wrote:

 Speaking of, I found this crazy wizardry which looks quite 
 interesting:

 https://github.com/multiarch/qemu-user-static


I played around with it.

1. It works. It's amazing. I guess it's a bit like Rosetta for 
Linux.

2. It's slow (about 8x). Probably don't try to build LLVM inside 
it.

3. There seems to be some problem with creating processes using 
std.process. Everything just segfaults. This prevents D tools 
like Dub from doing pretty much anything.
Sep 25 2021
parent kinke <noone nowhere.com> writes:
On Saturday, 25 September 2021 at 19:31:40 UTC, Vladimir 
Panteleev wrote:

 2. It's slow (about 8x). Probably don't try to build LLVM 
 inside it.


Lol yeah - I used to build LLVM in qemu for armhf, that took like 
3 full days. Later qemu versions seemed to be able to use 3 host 
CPU cores for emulating 3 virtual cores => down to 'only' 24 
hours. ;)
Sep 25 2021
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On Saturday, 25 September 2021 at 07:59:08 UTC, Vladimir 
Panteleev wrote:

 Hi,
 My goal: build a static binary of a D program for Linux-AArch64 
 from GitHub Actions (as an artifact).

 Does anyone have any advice in this direction?


I'm using an approach were I'm cross-compiling on the host and 
then link and run the tests in a Docker container with the help 
of QEMU:

https://github.com/jacob-carlborg/lime/blob/f3f0b5580b06568aeff38987148729dd4b4a3797/.github/workflows/ci.yml#L156-L172

Docker has great integration with QEMU, just specify the 
`--platform` flag when running a container.

Another approach would be to use Zig to cross-link. It supports 
automatically compiling the C standard library (glibc or musl) 
for its supported architectures. No need to install anything 
besides downloading Zig.

--
/Jacob Carlborg
Sep 26 2021
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 26 September 2021 at 16:30:04 UTC, Jacob Carlborg 
wrote:

 I'm using an approach were I'm cross-compiling on the host and 
 then link and run the tests in a Docker container with the help 
 of QEMU:


Very interesting, thanks! Though I guess linking elsewhere would 
preclude any kind of LTO :)
Sep 26 2021
next sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 27 September 2021 at 06:59:32 UTC, Vladimir Panteleev 
wrote:

 On Sunday, 26 September 2021 at 16:30:04 UTC, Jacob Carlborg 
 wrote:

 I'm using an approach were I'm cross-compiling on the host and 
 then link and run the tests in a Docker container with the 
 help of QEMU:


 Very interesting, thanks! Though I guess linking elsewhere 
 would preclude any kind of LTO :)


I was cross compiling and cross linking on my iMac for ARM with 
ld.lld, after having scraped only the necessary ubuntu libs and 
the ARM distribution of ldc.
For linking, it was something like that (copy/pasted from the D 
build script):


     "/usr/local/opt/llvm/bin/ld.lld ",
     "-o %o ",

     "--sysroot=/ ",
     "--build-id ",
     "--eh-frame-hdr ",
     "-m aarch64linux ",
     "--hash-style=gnu ",
     "-z now ",
     "-z relro ",

     "--lto-O2 ",
     "--gc-sections ",

     "-dynamic-linker /lib/ld-linux-aarch64.so.1 ",

     
"-L/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/gcc
aarch64-linux-gnu/7 ",
     
"-L/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/l
b/aarch64-linux-gnu ",
     
"-L/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib ",
     
"-L/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/l
b/aarch64-linux-gnu ",
     
"-L/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib ",

     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/aarch
4-linux-gnu/Scrt1.o ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/aarc
64-linux-gnu/crti.o ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/gcc/aarch64-lin
x-gnu/7/crtbeginS.o ",

     "%f ",

     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/ldc-1.27.1/
ib/libphobos2-ldc.a  ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/ldc-1.27.1/l
b/libdruntime-ldc.a ",

     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib/aarch64-lin
x-gnu/librt-2.27.so ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib/aarch64-lin
x-gnu/libdl-2.27.so ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib/aarch64-linux
gnu/libpthread.so.0 ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/aarch64-linux-gnu/li
pthread_nonshared.a ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib/aarch64
linux-gnu/libm.so.6 ",

     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib/aarch64
linux-gnu/libc.so.6 ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/aarch64-linux-
nu/libc_nonshared.a ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/lib/aarch64-linux-gnu/l
-linux-aarch64.so.1 ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/gcc/aarch64-
inux-gnu/7/libgcc.a ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/gcc/aarch64-lin
x-gnu/7/libgcc_s.so ",

     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/gcc/aarch64-l
nux-gnu/7/crtendS.o ",
     
"/Users/pinver/Projects/Workspace/Prefix/ubuntu_a64/18.10/usr/lib/aarch64-linux-gnu/crtn.o"
```
Sep 27 2021
prev sibling parent Kagamin <spam here.lot> writes:
On Monday, 27 September 2021 at 06:59:32 UTC, Vladimir Panteleev 
wrote:

 Very interesting, thanks! Though I guess linking elsewhere 
 would preclude any kind of LTO :)


The llvm-lto2 tool provides LTO as an isolated step without 
linking. If you have it as a cross-compiler.
Sep 28 2021