When targeting x86_64-unknown-linux-musl, the default features will successfully compile a binary that always segfaults when run (see #106). This is because the default features will try to dynamic link against libyara.so, which means adding it to the list of dynamic dependencies in the resulting ELF for it to be loaded by the ld (glibc) interpreter at the start of the program execution.
However, musl binaries produced by rustc do not have any interpreter, they jump straight to the ELF's entrypoint, and libyara.so is never loaded, even though it is listed as a dynamic dependencies in the ELF. This of course ultimately results in a segfault when trying to access any memory belonging to libyara.so, since it was not loaded in our address space.
In my opinion this is a bug in rustc, it should never allow dynamic linking when targeting musl, and this has been reported in this issue https://github.com/rust-lang/rust/issues/82193
Until it is fixed in rustc, this PR adds a new check in build.rs to abort compilation when dynamic linking and targeting musl, and prompts the user to use the yara-static feature instead to static link against libyara.a instead of libyara.so, because that's probably what they actually want when targeting musl.
When targeting
x86_64-unknown-linux-musl, the default features will successfully compile a binary that always segfaults when run (see #106). This is because the default features will try to dynamic link against libyara.so, which means adding it to the list of dynamic dependencies in the resulting ELF for it to be loaded by theld(glibc) interpreter at the start of the program execution.However, musl binaries produced by rustc do not have any interpreter, they jump straight to the ELF's entrypoint, and libyara.so is never loaded, even though it is listed as a dynamic dependencies in the ELF. This of course ultimately results in a segfault when trying to access any memory belonging to libyara.so, since it was not loaded in our address space.
In my opinion this is a bug in rustc, it should never allow dynamic linking when targeting musl, and this has been reported in this issue https://github.com/rust-lang/rust/issues/82193
Until it is fixed in rustc, this PR adds a new check in
build.rsto abort compilation when dynamic linking and targeting musl, and prompts the user to use theyara-staticfeature instead to static link against libyara.a instead of libyara.so, because that's probably what they actually want when targeting musl.