Undefined reference to `__memcpy_chk' with target x86_64-unknown-linux-musl

help
1

Hello,

I am trying to create a statically linked binary of a simple actix-web application. A cargo b --target x86_64-unknown-linux-musl works. It builds without errors and finally a statically linked binary is created in target/x86_64-unknown-linux-musl/debug

A build in release mode via cargo b --target x86_64-unknown-linux-musl -r breaks with the following error:

/tmp/zero/target/x86_64-unknown-linux-musl/release/deps/libzstd_sys-9b387b231def6026.rlib(5eeec2f4c1e9b3b6-zstd_v01.o): in function `ZSTD_decompressSequences':
          zstd_v01.c:(.text.ZSTD_decompressSequences+0x9d5): undefined reference to `__memcpy_chk'
          collect2: error: ld returned 1 exit status

It happens on Linux with Rust 1.79.0.

I searched for the error message on google, but unfortunately found nothing. What can I do to make it work in release mode?

2

You would need to talk to maintainers of zstd-sys crates about how to best build it with musl.

My guess would be that if you would build actual C version of zstd for Musl and provide appropriate pkg-config for it and then use feature pkg-config in zstd-sys then it may even work. But not 100% sure, when C libraries are involved everything becomes huge PITA very fast.

This has nothing to do with Rust but everything to do with how C version of libzstd is built and how zstd-sys finds (or, rather, not finds) a way to build it for Musl.

Good luck, you'll need it.

Translation from English to English: someone have built zstd_v01.c for glibc but then foolishly is trying to link it with Musl… be happy that everything actually fails at link stage instead of doing weird things at runtime.

3

I ran into a similar issue trying to compile a project using the "x86_64-unknown-linux-musl" target that had the libsqlite3_sys crate as a dependency. It was likewise failing to link with errors including "undefined reference to `__memcpy_chk'".

I believe the underlying issue was that the cc crate was building against the regular, glibc toolchain while I was linking against the static, musl one.

Ultimately I solved my problem by setting the following environment variable to tell the cc crate which compiler to use:

CC_x86_64-unknown-linux-musl='/path/to/my/x86_64-unknown-linux-musl-cc'

This was alongside my existing variable I was using to tell cargo which linker to use:

CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER='/path/to/my/x86_64-unknown-linux-musl-cc'

As an alternative, in other projects I've also had success using cargo-zigbuild when I didn't want to fuss as much with installing toolchains (aside from zig itself) and setting environment variables.

4

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.