On Saturday, 25 September 2021 at 20:12:09 UTC, kinke wrote:

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)

On Sunday, 26 September 2021 at 07:51:01 UTC, Vladimir Panteleev wrote:

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

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

It works!

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

Thank you!

On Sunday, 26 September 2021 at 12:31:12 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?

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.

On Saturday, 25 September 2021 at 07:59:08 UTC, Vladimir Panteleev 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:

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

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

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?

On Sunday, 26 September 2021 at 17:31:35 UTC, kinke wrote:

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

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.

On Sunday, 26 September 2021 at 20:00:15 UTC, Vladimir Panteleev wrote:

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.

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.

On Monday, 27 September 2021 at 02:27:32 UTC, kinke wrote:

No worries, I'll dig into this myself a bit more if I get more requests/complaints from tool users. Thanks!

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

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