armhf: Easier way to build against glibc > 2.17? (or lower dependency glibc requirements)

[Trayshar]

Heya! Im building my project, which depends on libudev-dev against arm-unknown-linux-gnueabihf(which compiles against glibc 2.17). After some tweaking (see #874) it managed to nearly compile, except I get
/lib/arm-linux-gnueabihf/libudev.so: undefined reference to getrandom@GLIBC_2.25'.
Building my own base image using crosstool-ng (see #734 for instructions) against glibc 2.27 works, but this was harder than expected since there seems to be no documentation outside the commit message in #734. Also, it's not good for shared projects, since my other colleagues don't have my "homemade" base image to compile with (same goes for CI) and compilation of this custom image took around ~2h on my machine.

Is there a way to either get a image like this automatically or lower the glibc requirements of libudev-dev?

[Alexhuszagh]

We have documentation elsewhere but we should probably improve it/move it to cross itself, probably the Wiki. For example, in cross-toolchains we have:

The config files are configured via [crosstool-ng/configure-all.sh](https://github.com/cross-rs/cross-toolchains/blob/main/crosstool-ng/configure-all.sh), which may be customized by the following environment variables:
- `GCC_VERSION`: The GCC version (default 8.3.0)
- `GLIBC_VERSION`: The glibc version (default 2.17)
- `LINUX_VERSION`: The Linux version (default 4.19.21)

The same thing is actually true for cross-rs. Maybe we could add it to the Wiki? Does that sound good?

So in this case, you should be able to auto-generate the config file you want with GLIBC_VERSION=2.27 crosstool-ng/configure.sh. We really should move this away from a bash script however and let you use it for individual targets.

[Trayshar]

It's pretty-much zero-setup (besides rustup + docker) for native Rust libraries, or those with vendored C++ dependencies, but yeah, for some odd cases it can be much more complex.

Yeah. I'll continue using cross for the forseeable future. It's a great tool.

To my suprise my build for amrhf that's linked against armv7-libudev still seems to work just fine.

This actually surprised me too, since I was fairly certain before I checked the architecture notes that it was ARMv7.

Oh, it is ARMv7 alright, I checked it too. I compile using a armv6 toolchain, getting an amrv6 binary, but linking against an armv7 library in the process. It's linked dynamically tho, so perhaps this is why? Also, I haven't tested every hardware combination my project can run on yet, doing so in the coming weeks. Maybe something related to this will pop up.

I do not have enough experience in this field to come up with a better solution tho (and sadly lack the time right now to get into it). More documentation on this would be great!

No worries, I'm lucky to have been a C++ developer before I started using Rust more, so I happen to be familiar with this. C++ packaging is an absolute mess, and I'm glad I can help with this.

Thank you for your service ^^

[Alexhuszagh]

@Trayshar I've updated the Wiki extensively and added a sample project for how to do this. This works out-of-the-box for ARMv6 targets. vcpkg, Meson, and Conan.

[Trayshar]

@Trayshar I've updated the Wiki extensively and added a sample project for how to do this. This works out-of-the-box for ARMv6 targets. vcpkg, Meson, and Conan.

Thank you very much for that. I can't seem to find the ARMv6 example tho, only dockerfiles and configuration for ARMv7 and ARMv8. Am I looking in the right place?

[Alexhuszagh]

@Trayshar I've updated the Wiki extensively and added a sample project for how to do this. This works out-of-the-box for ARMv6 targets. vcpkg, Meson, and Conan.

Thank you very much for that. I can't seem to find the ARMv6 example tho, only dockerfiles and configuration for ARMv7 and ARMv8. Am I looking in the right place?

Yep, just change this though to the ARMv6 image and it will work. This is because the toolchain compiles for ARMv6, so all this code will work (as long as you modify it for the compiler version in the README, which I believe is GCC 8.3.0):

# These are ordered from longest to shortest.
ARG VCKPKG_PROCESSOR=armhf
ARG PROCESSOR=arm
ARG SYSTEM=Linux
ARG TRIPLE=armelhf-unknown-linux-gnueabi
ARG QEMU=qemu-arm
ARG SYSROOT=/usr/arm-linux-gnueabihf
ARG CC=arm-linux-gnueabihf-gcc
ARG CXX=arm-linux-gnueabihf-g++
ARG AR=arm-linux-gnueabihf-ar
ARG STRIP=arm-linux-gnueabihf-strip

RUN mkdir -p /opt/cross/bin

COPY vcpkg-triple.sh /
RUN LINKAGE=static /vcpkg-triple.sh

COPY meson.sh /
RUN CPU_FAMILY=arm /meson.sh

COPY conan.sh /
RUN COMPILER=gcc COMPILER_VERSION="9" /conan.sh

[Alexhuszagh]

Also, the image build times are super quick (order of like 3-5 minutes), so you shouldn't have major issues with building the images and experimenting (or asking me for help). Just obviously, use cmake-rs or meson-rs with vcpkg or Conan, and not the raw commands, so it can properly integrate it with the Rust build system.