cross: x86_64-unknown-linux-gnu target generates GLIBC 2.18 symbols

I hit the same or similar problem just now, I’m trying to cross-compile to raspbian stretch (raspberry pi).

My binary has C dependencies statically linked in using the cmake crate.

What I did was, take Dockerfile.arm-unknown-linux-gnueabihf and change the FROM line to debian:stretch, thinking that would do it. ldd --version shows GLIBC 2.24.

The build works fine, but the binary it produces links to GLIBC 2.28 (which is installed on the host, debian buster).

Weirdly, I got the same problem by running rustup inside the container (the project is in a bind mount at /project) and then running cargo manually in the container. I don’t understand where it’s picking up the newer GLIBC from. Could docker somehow inject the wrong version for compatibility with the host?

Dockerfile:

FROM debian:stretch

COPY common.sh lib.sh /
RUN /common.sh

COPY cmake.sh /
RUN /cmake.sh

COPY xargo.sh /
RUN /xargo.sh

# make openssl work
RUN apt-get update
RUN dpkg --add-architecture armhf && \
    apt-get update && \
    apt-get install --assume-yes libssl-dev:armhf libssl1.1:armhf openssl:armhf curl xz-utils
RUN ln -s /usr/include/arm-linux-gnueabihf/openssl/opensslconf.h /usr/include/openssl/
ENV OPENSSL_LIB_DIR /usr/lib/arm-linux-gnueabihf/
ENV OPENSSL_INCLUDE_DIR /usr/include/
ENV PKG_CONFIG_PATH /usr/local/lib/pkgconfig
ENV PKG_CONFIG_LIBDIR_arm_unknown_linux_gnueabihf=/usr/lib/arm-linux-gnueabihf/pkgconfig

RUN mkdir /usr/arm-linux-gnueabihf \
 && cd /usr/arm-linux-gnueabihf \
 && export TOOLCHAIN_VERSION=8.3-2019.03 \
 && curl --retry 3 -sSfL https://developer.arm.com/-/media/Files/downloads/gnu-a/${TOOLCHAIN_VERSION}/binrel/gcc-arm-${TOOLCHAIN_VERSION}-x86_64-arm-linux-gnueabihf.tar.xz -O \
 && tar --strip-components 1 -xJf gcc-arm-${TOOLCHAIN_VERSION}-x86_64-arm-linux-gnueabihf.tar.xz \
 && rm gcc-arm-${TOOLCHAIN_VERSION}-x86_64-arm-linux-gnueabihf.tar.xz

ENV PATH /usr/arm-linux-gnueabihf/bin:$PATH

ENV CARGO_TARGET_ARM_UNKNOWN_LINUX_GNUEABIHF_LINKER=arm-linux-gnueabihf-gcc \
    CARGO_TARGET_ARM_UNKNOWN_LINUX_GNUEABIHF_RUNNER=qemu-arm \
    CC_arm_unknown_linux_gnueabihf=arm-linux-gnueabihf-gcc \
    CXX_arm_unknown_linux_gnueabihf=arm-linux-gnueabihf-g++ \
    QEMU_LD_PREFIX=/usr/arm-linux-gnueabihf/arm-linux-gnueabihf/libc \
    LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/arm-linux-gnueabihf/libc/lib:/usr/arm-linux-gnueabihf/arm-linux-gnueabihf/lib:/usr/arm-linux-gnueabihf/lib \
    RUST_TEST_THREADS=1

# I tried this to run rustc manually
RUN curl https://sh.rustup.rs -sSf | sh -s -- -y
ENV PATH="/root/.cargo/bin:${PATH}"
RUN rustup target add arm-unknown-linux-gnueabihf

edit: removed libc6-dev git from the apt install command, as I tested and they are not needed. Same issue without them.

Still seeing this after #501 when trying to build for RHEL 7 from MacOS – even with the alternative approach provided by @otavio:

$ cargo clean
$ cross build --target x86_64-unknown-linux-gnu --release
$ scp target/x86_64-unknown-linux-gnu/release/my-app some-rhel7-box:
$ ssh some-rhel7-box
$ objdump -T ~/my-app | grep GLIBC_2.18
0000000000000000  w   DF *UND*  0000000000000000  GLIBC_2.18  __cxa_thread_atexit_impl

Does this require a nightly toolchain and xargo? If so, that’s not working, either, for some reason I’ve been unable to diagnose:

$ cat Cross.toml
# Add support for building RHEL 7 binaries, which only require glibc <= 2.17.
# Reference: <https://github.com/rust-embedded/cross/issues/455>
[target.x86_64-unknown-linux-gnu]
xargo = true
#image = "ossystems/rust-cross:x86_64-linux-compat-0.2.1"
$ rustup override set nightly
info: using existing install for 'nightly-x86_64-apple-darwin'
info: override toolchain for '/Users/d6lu/workspaces/bfd/beneficiary-fhir-data.git/apps/utils/db-query-checker' set to 'nightly-x86_64-apple-darwin'

  nightly-x86_64-apple-darwin unchanged - rustc 1.55.0-nightly (014026d1a 2021-07-19)
$ cross build --target x86_64-unknown-linux-gnu --release
error: `rust-src` component not found. Run `rustup component add rust-src`.
note: run with `RUST_BACKTRACE=1` for a backtrace
$ rustup component add rust-src
info: component 'rust-src' is up to date
$ cross build --target x86_64-unknown-linux-gnu --release
error: `rust-src` component not found. Run `rustup component add rust-src`.
note: run with `RUST_BACKTRACE=1` for a backtrace

😞

We can prepare a PR for sure, assuming upstream wishes it.

If you look at the diff in commit https://github.com/OSSystems/rust-cross-images/commit/e665cee0c244cc1b6a23a8ae8d4f3c99f60dc7ff you’ll notice it is a little convoluted as we have to do some workarounds to allow the use with this old base system.

So to do the PR, we’d need to receive some direction on how it’d be better to approach this so we work in a way it’s likely to be accepted.

@Hoverbear in meantime you could use those images and get the builds going 😉

We finished it up and created two images, based on Debian 6.

You can use the target.{{TARGET}}.image field in Cross.toml to use our custom Docker images for a specific target:

[target.{{TARGET}}]
image = "ossystems/rust-cross:{{TAG}}"

Refer to the table below for the TARGET and TAG available combinations:

Target	Image Tag	libc	GCC	C++	QEMU	test
i686-unknown-linux-gnu	i686-linux-compat-0.2.1	2.11	4.4.5	✓	N/A	✓
x86_64-unknown-linux-gnu	x86_64-linux-compat-0.2.1	2.11	4.4.5	✓	N/A	✓
aarch64-unknown-linux-gnu	aarch64-unknown-linux-gnu-libarchive-0.2.1	2.23	5.3.1	✓	4.2.0	✓
armv7-unknown-linux-gnueabihf	armv7-unknown-linux-gnueabihf-libarchive-0.2.1	2.23	5.3.1	✓	4.2.0	✓

Please see our README at https://github.com/OSSystems/rust-cross-images for more details and please feel free to provide fixes there if need.