Failure to build on aarch64-linux for rmp 0.8.11

[brooksmtownsend]

For rmp-0.8.11, using https://github.com/cross-rs/cross to compile rmp for aarch64-linux-unknown-gnu apparently attempts to use the paste::paste macro which attempts to use an x86 version of libc. This is not present in 0.8.10, and pinning rmp specifically to that version will fix the issue.

If you're interested, here is the GH Action where the build fails https://github.com/wasmCloud/capability-providers/runs/6499031722?check_suite_focus=true and the Rust build stacktrace:

error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /target/release/deps/libpaste-84b805ce4b9c7c6a.so)
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/rmp-0.8.11/src/decode/mod.rs:61:20
   |
61 |                 Ok(paste::paste! {
   |                    ^^^^^

error: cannot determine resolution for the macro `paste::paste`
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/rmp-0.8.11/src/decode/mod.rs:61:20
    |
61  |                   Ok(paste::paste! {
    |                      ^^^^^^^^^^^^
...
118 | /     read_byteorder_utils!(
119 | |         read_data_u16 => u16,
120 | |         read_data_u32 => u32,
121 | |         read_data_u64 => u64,
...   |
126 | |         read_data_f64 => f64
127 | |     );
    | |_____- in this macro invocation
    |
    = note: import resolution is stuck, try simplifying macro imports
    = note: this error originates in the macro `read_byteorder_utils` (in Nightly builds, run with -Z macro-backtrace for more info)

error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /target/release/deps/libpaste-84b805ce4b9c7c6a.so)
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/rmp-0.8.11/src/decode/mod.rs:148:11
    |
148 |         $(paste::paste! {
    |           ^^^^^

error: cannot determine resolution for the macro `paste::paste`
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/rmp-0.8.11/src/decode/mod.rs:148:11
    |
148 |           $(paste::paste! {
    |             ^^^^^^^^^^^^
...
158 | / wrap_data_funcs_for_compatibility!(
159 | |     u8, u16, u32, u64,
160 | |     i8, i16, i32, i64,
161 | |     f32, f64
162 | | );
    | |_- in this macro invocation
    |
    = note: import resolution is stuck, try simplifying macro imports
    = note: this error originates in the macro `wrap_data_funcs_for_compatibility` (in Nightly builds, run with -Z macro-backtrace for more info)

error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /target/release/deps/libpaste-84b805ce4b9c7c6a.so)
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/rmp-0.8.11/src/encode/mod.rs:127:17
    |
127 |                 paste::paste! {
    |                 ^^^^^

error: cannot determine resolution for the macro `paste::paste`
   --> /cargo/registry/src/github.com-1ecc6299db9ec823/rmp-0.8.11/src/encode/mod.rs:127:17
    |
127 |                   paste::paste! {
    |                   ^^^^^^^^^^^^
...
175 | /     write_byteorder_utils!(
176 | |         write_data_u16 => u16,
177 | |         write_data_u32 => u32,
178 | |         write_data_u64 => u64,
...   |
183 | |         write_data_f64 => f64
184 | |     );
    | |_____- in this macro invocation
    |
    = note: import resolution is stuck, try simplifying macro imports
    = note: this error originates in the macro `write_byteorder_utils` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `rmp` due to 6 previous errors

Please let me know if I can provide any more information

[kornelski]

I don't think this has anything to do with this crate. Error about GLIBC_2.29 suggests that your cross-compilation setup is broken, and this in turn breaks compiler plugins for proc-macros, which in turn breaks anything using them.

[brooksmtownsend]

I don't think this has anything to do with this crate. Error about GLIBC_2.29 suggests that your cross-compilation setup is broken, and this in turn breaks compiler plugins for proc-macros, which in turn breaks anything using them.

It certainly has to do with the cross-compilation setup, but I am curious about what changed in the proc macro here to change whether or not the crate can compile in a previously working setup. Did anything change with the use of libpaste with the most recent patch version?

[kornelski]

This error:

error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.29' not found (required by /target/release/deps/libpaste-84b805ce4b9c7c6a.so)

is from a dynamic linker, which suggests that libpaste failed to load. So the paste macro fails to run, because it couldn't be loaded by the compiler, because you have broken glibc.

I think it's not the fault of libpaste, because it didn't even run at all. Possibly every proc macro would fail the same way in your unusably-broken setup, and this just happens to be the first one that is used.

[kornelski]

Note that Rust requires you to have support for both native and cross platforms at the same time, because compile-time artifacts like proc macros and build.rs scripts run on the native/host platform. So if your cross-compilation setup forces all code to be cross-compiled, it will break these.

Personally I never managed to get cross-rs/cross working. For cross-compilation on Debian from ARM to x86 I use just this:

FROM rust:1-slim-bullseye
RUN rustup target add x86_64-unknown-linux-gnu
RUN dpkg --add-architecture amd64
RUN apt-get update; apt-get install pkg-config libssl-dev:amd64 libsqlite3-dev:amd64 build-essential crossbuild-essential-amd64 -y

[brooksmtownsend]

What this seemed to come down to is sequentially building for different targets using cross, and each build leaving behind intermediate build artifacts. Apparently, something about the paste library kept around the x86 linux version and attempting to compile with the x86 version of GLIBC (hence the error).

I was able to fix this by rm -rf target/release/build && rm -rf target/release/deps between each compilation target, in case it helps others. You were correct that it was not due to the rmp library, it was just a strange red herring that reverting to an older version seemed to "fix" the issue