Cross-compiling a static binary from GitHub Actions

[Vladimir Panteleev]

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