LLVM v19.1.x: For some target architectures, musl cross-builds fail unless include paths are specified in BINDGEN_EXTRA_CLANG_ARGS (LLVM v18.1.x is fine)

[m-ueberall]

(This might be related to issue #28 and/or specific to the way bindgen is used in this repository when building libsignal_jni.so for different <arch>-unknown-linux-musl* targets in a glibc-based build environment.)

At least for musl architectures riscv64, mips64el, powerpc64le, s390x (see <arch> above), it is not possible anymore to successfully build the previously mentioned dynamic library when cross-compiling using LLVM v19.1.x (x<6) instead of v18.1.y on Ubuntu(/Debian, since they share the same toolchain) without running into the following problem:

  /usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
  thread 'main' panicked at /tmp/libsignal_ubuntu2004-x86_64.tmp/crates/boring/boring-sys/build/main.rs:756:39:
  Unable to generate bindings: ClangDiagnostic("/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found\n")
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
`cargo build --profile dev --verbose -p libsignal-jni` exited with status code 101

The above error is also discussed in rust-bindgen issue #2612, but the suggested solution at the bottom does not apply here.

If you choose to cross-compile for target aarch64-unknown-linux-musl on an amd64/x86_64 host and vice versa (or, e.g., for architectures i686, armv7, loongarch64), everything works as expected; also, target riscv64-unknown-linux-musl will work in a native build environment (w/o the need to cross-compile). (I suspect the same would hold true for other native build environments, but setting those up is not that straightforward.)

At least for the above mentioned four architectures, the fatal error in question can be fixed by explicitly specifying the "default" search paths in BINDGEN_EXTRA_CLANG_ARGS as follows:

export BINDGEN_EXTRA_CLANG_ARGS="-I/usr/include -I/usr/include/<arch>-linux-musl -I/usr/lib/gcc-cross/<arch>-linux-gnu[abi[64]]/<gcc-version>/include"

... which is odd because the location of the include paths follows the same naming scheme for all architectures (some work, some don't).

(I haven't tried whether a subset would suffice, but all of the above include paths should already be visible to the C[++] compiler(s) in question anyway.)

Whether or not the above change in behaviour is considered an issue, it might be worthwhile to document it "somewhere" (as without connecting the problem to rust-bindgen and learning about the existence of BINDGEN_EXTRA_CLANG_ARGS, this can cost users a lot of time looking at the wrong set of include paths).

[jrose-signal]

You should probably file this on the upstream cloudflare/boring; we're not the primary maintainers of boring and unlikely to get to this soon. I don't know enough about this particular cross-compilation to know whether passing GCC headers to the LLVM-based bindgen is really the best idea, nor whether using BINDGEN_EXTRA_CLANG_ARGS should be preferred over plain old CPATH/CFLAGS (even though you seem to be getting past the build step). (The few times I've compiled for musl, I've used --sysroot path/to/sdk collected explicitly rather than relying on my host headers being close enough.)

[m-ueberall]

You should probably file this on the upstream cloudflare/boring; we're not the primary maintainers of boring and unlikely to get to this soon.

I see. Will try to reproduce this using their code base and re-file this if possible, then. At least it looks like there's already an open issue that deals with cross-compiling, so maybe this can/might indeed be addressed upstream.