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
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libc.a(iofclose.o): In function `_IO_new_fclose':
(.text+0x256): undefined reference to `_Unwind_Resume'
Note the x86_64-linux-gnu in there!
The rust code (as is standard) merely says #[link(name="c")], which is translated into "-l" "c" in the link command, but the cc (which on my system is a glibc one) is searching in the standard glibc locations rather than the muslibc ones (which would be -L/usr/lib/x86_64-linux-musl according to musl-gcc -v <the rest of the above command>). Not sure how to guess the correct location to search, one obvious solution might be to use musl-gcc in place of cc when linking for the ...-musl targets, but that's not necessarily correct on all systems (e.g. on Alpine where cc would be correct as that system is musl-native).
The text was updated successfully, but these errors were encountered:
Ah, thank you, that's perfect. There's a bit of a lack of information about how to use the -musl targets (or how to cross compile), there used to be https://doc.rust-lang.org/1.12.1/book/advanced-linking.html but this seems to have been removed in newer editions.
While investigating #47493 I tried compiling the linked example code (https://gist.github.com/steveklabnik/5abd59a8fe7e5abda3db58bd8c208fbb) against the
x86_64-unknown-linux-musl
and noticed something weird - glibc was linked into my binary (unsuccessfully but still...):Link command:
Selected error:
Note the
x86_64-linux-gnu
in there!The rust code (as is standard) merely says
#[link(name="c")]
, which is translated into"-l" "c"
in the link command, but thecc
(which on my system is a glibc one) is searching in the standard glibc locations rather than the muslibc ones (which would be-L/usr/lib/x86_64-linux-musl
according tomusl-gcc -v <the rest of the above command>
). Not sure how to guess the correct location to search, one obvious solution might be to usemusl-gcc
in place ofcc
when linking for the...-musl
targets, but that's not necessarily correct on all systems (e.g. on Alpine wherecc
would be correct as that system is musl-native).The text was updated successfully, but these errors were encountered: