segment fault in alpine linux

[plusls]

error: failed to run custom build command for `xxxxv0.1.0 (/xxxx)`
Caused by:
  process didn't exit successfully: `/builds/xxxx/target/release/build/xxxx-c3fa4b775c30545d/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
  --- stdout
  cargo:rerun-if-changed=/builds/xxxx/custom_mime

And in my gdb I found that the reference of magic_open is null, I have no ideal why.

alpine env: based on rust:1.76-alpine

apk add musl-dev file-dev

[robo9k]

Hej @plusls, could you add some more detail about your setup?

Which version of magic-sys are you using? Are you using magic-sys directly or via the magic crate and which version? Which version of the musl-dev and file-dev packages did you end up with? How are you building your project, did you set any environment variables to configure magic-sys? What did you debug with gdb, your build-script? When/where is magic_open set to null?

[plusls]

I use the rust-magic-sys 0.3.0, and I try to use it in docker image rust:alpine，with deps

apk add musl-dev file-dev

deps version:

• file-dev: file-dev-5.45-r1 x86_64
• musl-dev: musl-dev-1.2.4_git20230717-r4

I direct build my program with cargo build --release, without other envirom var.

my code:

fn main() {
    unsafe {magic_sys::magic_open(0)};
    println!("Hello, world!");
}

And I saw that

I found that it success link to libmagic

I don't know why, the value in got table of magic_open is null ptr, I debug it with gdb and reverse it with ida pro

[plusls]

any progress? @robo9k

[robo9k]

I can reproduce this, but since I'm usually using neither Alpine nor MUSL I don't really know why the shared libmagic library is not loaded, even though it is being linked against.

You can fix this by "dynamically linking" to libc (but this seems to link to libgcc_s, compare with your ldd screenshot):

$ RUSTFLAGS="-C target-feature=-crt-static" cargo build

This pretty much seems to be the same as https://users.rust-lang.org/t/segfault-when-linking-against-shared-libraries-on-alpine/98629 and even the gdb backtrace is as unhelpful there.