tikv-jemalloc-sys 0.5.0: Databend cannot be built on musl targets

[PsiACE]

  = note: /usr/bin/ld: /home/work/databend/target/x86_64-unknown-linux-musl/debug/deps/libtikv_jemalloc_sys-5844e04c26a2be2a.rlib(prof_sys.pic.o): undefined reference to symbol 'pthread_getname_np@@GLIBC_2.34'
          /usr/bin/ld: /usr/lib64/libc.so.6: error adding symbols: DSO missing from command line
          collect2: error: ld returned 1 exit status

target: x86_64-unknown-linux-musl

Build failure after upgrade to 0.5.0.

[BusyJay]

Perhaps this should be send to jemalloc/jemalloc as well. Without change from upstream or without updating musl versions bundled by rust, we may not be able to make it work.

[Xuanwo]

Related to https://github.com/tikv/pprof-rs/issues/142

Both libc and musl have added support for pthread_getname_np, but rustc can't find them.

---

updating musl versions bundled by rust

If I understand correctly, do you mean rust has its own bundled musl? So it doesn't work if we just upgrade our own musl?

[BusyJay]

do you mean rust has its own bundled musl?

Yes.

So it doesn't work if we just upgrade our own musl?

No, it won't work. Though I'm not sure if it's caused by outdated bundle musl yet.

[Xuanwo]

Works with RUSTFLAGS="-C target-feature=-crt-static" cargo build --target x86_64-unknown-linux-musl

[Xuanwo]

But test still failed:

  = note: /usr/bin/ld: /home/xuanwo/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/libtest-39fc138fafb03235.rlib(test-39fc138fafb03235.test.08afccba-cgu.0.rcgu.o): in function `std::f64::<impl f64>::floor':
          /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/f64.rs:51: undefined reference to `floor'
          /usr/bin/ld: /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/f64.rs:51: undefined reference to `floor'
          /usr/bin/ld: /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/f64.rs:51: undefined reference to `floor'
          /usr/bin/ld: /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/std/src/f64.rs:51: undefined reference to `floor'
          collect2: error: ld returned 1 exit status

  = help: 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#cargorustc-link-libkindname)

[tavianator]

So what's happening for me in fd is that jemalloc's ./configure is run with CC=musl-gcc, which uses my system's musl installation. That version is 1.2.3 so it has pthread_getname_np, and jemalloc thinks it can use it. But then Rust's musl version doesn't have it, leading to link failure.

I am a little surprised that cc-rs just uses the system's musl-gcc. It would be more robust to point it at Rust's bundled musl libc.

This patch is a workaround, is it worth a PR?

diff --git a/jemalloc-sys/build.rs b/jemalloc-sys/build.rs
index b4c0266..c1318ac 100644
--- a/jemalloc-sys/build.rs
+++ b/jemalloc-sys/build.rs
@@ -153,6 +153,10 @@ fn main() {
         cmd.arg("--with-lg-page=14");
     }
 
+    if target.contains("musl") {
+        cmd.env("je_cv_pthread_getname_np", "no");
+    }
+
     // collect `malloc_conf` string:
     let mut malloc_conf = String::new();
 

[BusyJay]

Thanks for the workaround. I think it's the same as setting the environment when invoking build like env je_cv_pthread_getname_np=no cargo build. If it's really caused by some outdated bundled library, I would keep the workaround in applications as the bundled library will get upgraded finally.

[conblem]

Has this been fixed by the update of Musl in Rust 1.71?

[Amanieu]

Yes it is.