You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When attempting to compile a project using jemallocator on the rust:1.44.1-alpine3.12 container, linking fails with jemalloc/src/jemalloc.c:700: undefined reference to 'secure_getenv'. This error appears to caused by Alpine 3.12's system libc using musl v1.1.24, while Rust is bundling musl v1.1.22 in liblibc.
secure_getenv was added to musl in v1.1.24. jemalloc's configure script detects that the function is available in /usr/lib/libc.a, but linking jemalloc-sys to liblibc-2c7c7c631d98bf98.rlib fails as that symbol is not present in the bundled musl v1.1.22.
This problem does not occur with rustc 1.46.0-nightly (f455e46ea 2020-06-20) as the bundled musl has since been upgraded to v1.1.24.
I expected to see this happen: I am able to successfully build my Rust program against jemallocator when using the x86_64-unknown-linux-musl toolchain.
This may have the same root cause as #61328, though only one symbol is missing in this case.
I don't know if there's a way to prevent this, but a warning would be useful it the version mismatch can be detected.
I also didn't come across any documentation on how Rust bundles its own libc other than notes in issues. Is this specific to the musl toolchain? It would be useful to have this noted somewhere, perhaps in the 2018 edition notes.
The text was updated successfully, but these errors were encountered:
This should be addressed by #72274, which is currently on its way to being fixed (#72738).
If linking musl dynamically (-Ctarget-feature=-crt-static) is acceptable for you, then it can be used as a workaround because it disables the use of bundled libc.
When attempting to compile a project using
jemallocator
on the rust:1.44.1-alpine3.12 container, linking fails withjemalloc/src/jemalloc.c:700: undefined reference to 'secure_getenv'
. This error appears to caused by Alpine 3.12's system libc usingmusl
v1.1.24, while Rust is bundlingmusl
v1.1.22 inliblibc
.secure_getenv
was added tomusl
in v1.1.24.jemalloc
's configure script detects that the function is available in/usr/lib/libc.a
, but linkingjemalloc-sys
toliblibc-2c7c7c631d98bf98.rlib
fails as that symbol is not present in the bundledmusl
v1.1.22.This problem does not occur with
rustc 1.46.0-nightly (f455e46ea 2020-06-20)
as the bundledmusl
has since been upgraded to v1.1.24.I tried this code:
main.rs
Cargo.toml
I expected to see this happen: I am able to successfully build my Rust program against
jemallocator
when using thex86_64-unknown-linux-musl
toolchain.Instead, this happened: Linking fails with error:
Meta
rustc --version --verbose
:This may have the same root cause as #61328, though only one symbol is missing in this case.
I don't know if there's a way to prevent this, but a warning would be useful it the version mismatch can be detected.
I also didn't come across any documentation on how Rust bundles its own
libc
other than notes in issues. Is this specific to themusl
toolchain? It would be useful to have this noted somewhere, perhaps in the 2018 edition notes.The text was updated successfully, but these errors were encountered: