MUSL Bazelmod Example fails to compile on Ubuntu 20.04 with GLIBC 2.31

[marvin-hansen]

Repro:
https://github.com/marvin-hansen/rules_rust_fork/tree/bzlmod-musl/examples/bzlmod/musl_hello_world

Distro: Ubuntu 20,04
Platform: x86_64 GNU/Linux
The repro was tested in a VM in Orbstack (MacOS) since I don't have an Intel box around anymore.

rules_rust: commit 6086030c
aspect_bazel_lib: 2.5.0
toolchains_musl: 0.1.17 (also tested with 0.1.19)

CARGO_BAZEL_REPIN=true bazel build //...

bazel build //...

Error:

  /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/sys/pal/unix/os.rs:778: 
undefined reference to 

`gnu_get_libc_version'

          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)

error: aborting due to 1 previous error

The error message suggests the libgc binary is incompatible with musl libc.

gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
GNU ld (GNU Binutils for Ubuntu) 2.34
ldd (Ubuntu GLIBC 2.31-0ubuntu9.16) 2.31

The MUSL config is an exact carbon copy of the WORKSPACE example
just moved into a WORKSPACE.bazemod file; the original WORKSPACE example compiles
on the same VM so don't know what to say here.

After having tried a gazillion different MUSL Bzlmod configurations over the past two months to no avail,
I think it is simply most honest to put a note in the documentation that MUSL cannot be used with Bazelmod and just leave it there.

[illicitonion]

This is an interestingly different error from the others - the failure here is when building process_wrapper (an exec-config tool), which is using musl as the C++ toolchain, but is using the gnu rust toolchain. Passing --host_platform=//platforms:linux_x86_64_musl fixes this, because it tells Bazel that the host platform should be treated as a musl one, which forces the correct musl rust toolchain to be used.

I suspect this would also be fixed by registering a C++ toolchain (e.g. the LLVM toolchain) which allows for non-cross-compilation.

But I agree that this should probably work out of the box, or at least we should give a way to not register the gnu -> gnu rust toolchain so that the musl one gets picked by default if you don't have a non-musl non-cross-compiling C++ toolchain...

[marvin-hansen]

Thank you @illicitonion

When I add the

--host_platform=//platforms:linux_x86_64_musl

flag, I get another gazillion errors of various kinds in my VM.

I've replicated the exact same error on two different Linux VM's
See log below.

bazel build //... --host_platform=//platforms:linux_x86_64_musl

INFO: Analyzed 6 targets (0 packages loaded, 0 targets configured).
ERROR: /home/marvin/.cache/bazel/_bazel_marvin/a8d07b7bc288d446ce40d9369eca130e/external/cu__zerocopy-0.7.35/BUILD.bazel:16:13: Compiling Rust rlib zerocopy v0.7.35 (141 files) failed: (Exit 1): process_wrapper failed: error executing Rustc command (from target @@cu__zerocopy-0.7.35//:zerocopy) bazel-out/k8-opt-exec-ST-5fbe191395fc/bin/external/rules_rust~/util/process_wrapper/process_wrapper --subst 'pwd=${pwd}' -- ... (remaining 36 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
error[E0463]: can't find crate for `zerocopy_derive`
   --> external/cu__zerocopy-0.7.35/src/lib.rs:285:9
    |
285 | pub use zerocopy_derive::Unaligned;
    |         ^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `zerocopy_derive`
   --> external/cu__zerocopy-0.7.35/src/lib.rs:293:9
    |
293 | pub use zerocopy_derive::KnownLayout;
    |         ^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `zerocopy_derive`
    --> external/cu__zerocopy-0.7.35/src/lib.rs:1118:9
     |
1118 | pub use zerocopy_derive::FromZeroes;
     |         ^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `zerocopy_derive`
    --> external/cu__zerocopy-0.7.35/src/lib.rs:1733:9
     |
1733 | pub use zerocopy_derive::FromBytes;
     |         ^^^^^^^^^^^^^^^ can't find crate

error[E0463]: can't find crate for `zerocopy_derive`
    --> external/cu__zerocopy-0.7.35/src/lib.rs:2599:9
     |
2599 | pub use zerocopy_derive::AsBytes;
     |         ^^^^^^^^^^^^^^^ can't find crate

error[E0432]: unresolved import `crate::KnownLayout`
  --> external/cu__zerocopy-0.7.35/src/util.rs:21:34
   |
21 |     use crate::{util::AsAddress, KnownLayout, _CastType};
   |                                  ^^^^^^^^^^^

error[E0277]: the trait bound `byteorder::U16<O>: FromZeroes` is not satisfied
   --> external/cu__zerocopy-0.7.35/src/byteorder.rs:292:49
    |
292 |               impl_or_verify!(O => FromZeroes for $name<O>);
    |                                                   ^^^^^^^^ the trait `FromZeroes` is not implemented for `byteorder::U16<O>`
...
465 | / define_type!(
466 | |     A,
467 | |     U16,
468 | |     u16,
...   |
477 | |     [U32, U64, U128]
478 | | );
    | |_- in this macro invocation
    |
    = help: the following other types implement trait `FromZeroes`:
              ()
              *const T
              *mut T
              ManuallyDrop<T>
              MaybeUninit<T>
              Option<&T>
              Option<&mut T>
              Option<NonNull<T>>
            and 65 others
note: required by a bound in `byteorder::_::_::Subtrait`
   --> external/cu__zerocopy-0.7.35/src/macros.rs:323:29
    |
323 |               trait Subtrait: $trait {}
    |                               ^^^^^^ required by this bound in `Subtrait`
    |
   ::: external/cu__zerocopy-0.7.35/src/byteorder.rs:465:1
    |
465 | / define_type!(
466 | |     A,
467 | |     U16,
468 | |     u16,
...   |
477 | |     [U32, U64, U128]
478 | | );
    | |_- in this macro invocation
    = note: this error originates in the macro `define_type` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the trait bound `byteorder::U16<O>: FromBytes` is not satisfied
   --> external/cu__zerocopy-0.7.35/src/byteorder.rs:293:48
    |
293 |               impl_or_verify!(O => FromBytes for $name<O>);
    |                                                  ^^^^^^^^ the trait `FromBytes` is not implemented for `byteorder::U16<O>`
...
465 | / define_type!(
466 | |     A,
467 | |     U16,
468 | |     u16,
...   |
477 | |     [U32, U64, U128]
478 | | );
    | |_- in this macro invocation
    |
    = help: the following other types implement trait `FromBytes`:
              ()
              ManuallyDrop<T>
              MaybeUninit<T>
              Option<NonZero<i128>>
              Option<NonZero<i16>>
              Option<NonZero<i32>>
              Option<NonZero<i64>>
              Option<NonZero<i8>>
            and 31 others
note: required by a bound in `byteorder::_::_::Subtrait`
   --> external/cu__zerocopy-0.7.35/src/macros.rs:323:29
    |
323 |               trait Subtrait: $trait {}
    |                               ^^^^^^ required by this bound in `Subtrait`
    |

[marvin-hansen]

Just a quick update, I managed to get a much larger and way more complex repo (>70 crates) to build with multiple MUSL cross targets; However, it only worked without MUSL linking and just compiling. I still cannot pinpoint this issue, but it seems to be more of a static linking issue rather than anything else. A quick look into the Rust issue tracker, though, reveled an abyss of complex issues related to static linking so I really don't know about this.

I mean, the way I see it is that MUSL fills a massive gap left by LLVM for several platform triplets so I suppose documenting some examples accordingly should at lest enable a lot of use cases where static linking isn't required, but an LLVM target isn't available either so it looks net positive to me.

Would it be worth to add some MUSL non-static linking examples to the Bzlmod folders?

Thoughts?