September 26

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_LDC_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)

September 26

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

September 26

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!

September 26

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.

September 26

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

September 26

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?

September 26

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.

September 27

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.

September 27

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!

September 27

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 :)

1 2 3 4