shuttle
shuttle copied to clipboard
cargo-shuttle build error due to missing iconv symbols (MacOS, arm64, MacPorts)
I am not a rust or cargo expert yet, but I would assume that cargo install cargo-shuttle
is supposed to work in most cases. However, I am getting build problems due to undefined symbols:
error: linking with `cc` failed: exit status: 1
|
= note: "cc" "-arch" "arm64" "/var/folders/vd/z8g1y2yn2j78c3fx0_mqs... [3kb snipped] "-liconv" "-framework" "Security" "-framework" "CoreFoundation" "-lssl" "-lcrypto" "-lz" "-lcurl" "-framework" "CoreFoundation" "-framework" "SystemConfiguration" "-framework" "Security" "-framework" "CoreFoundation" "-liconv" "-lSystem" "-lresolv" "-lc" "-lm" "-liconv" "-L" "/Users/hmeine/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib" "-o" "/var/folders/vd/z8g1y2yn2j78c3fx0_mqsbdc0000gn/T/cargo-install1nPtmP/release/deps/cargo_shuttle-7b219432e8627bc2" "-Wl,-dead_strip" "-nodefaultlibs"
= note: Undefined symbols for architecture arm64:
"_iconv", referenced from:
_git_fs_path_iconv in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
(maybe you meant: _git_fs_path_iconv_clear, _git_fs_path_iconv , _git_fs_path_iconv_init_precompose )
"_iconv_close", referenced from:
_git_fs_path_direach in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
_git_fs_path_iconv_clear in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
_git_fs_path_diriter_free in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
_git_fs_path_dirload in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
"_iconv_open", referenced from:
_git_fs_path_direach in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
_git_fs_path_iconv_init_precompose in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
_git_fs_path_diriter_init in liblibgit2_sys-f1801d163fee174d.rlib(fs_path.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: failed to compile `cargo-shuttle v0.5.2`, intermediate artifacts can be found at `/var/folders/vd/z8g1y2yn2j78c3fx0_mqsbdc0000gn/T/cargo-install1nPtmP`
Some information on my system:
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.60.0 (7737e0b5c 2022-04-04)`
The following ports are currently installed:
libgit2 @1.5.0_0+threadsafe (active)
libiconv @1.17_0+universal (active)
Port libiconv contains:
/opt/local/bin/iconv
/opt/local/include/iconv.h
/opt/local/include/libcharset.h
/opt/local/include/localcharset.h
/opt/local/lib/libcharset.1.dylib
/opt/local/lib/libcharset.a
/opt/local/lib/libcharset.dylib
/opt/local/lib/libiconv.2.dylib
/opt/local/lib/libiconv.a
/opt/local/lib/libiconv.dylib
...
I can see that -liconv
appears thrice on the cmdline, and one of the first linker paths specified is "-L" "/opt/local/lib"
, which is also the location of libiconv. Any hints on how to debug this further or even better, how to get cargo-shuttle to build?
Hey @hmeine! I don't think this is a cargo-shuttle
specific issue, but maybe I can lead you in the right direction. I had a look around and I found some threads that seem relevant to your issue:
- This answer may do the trick (found here: https://github.com/cargo-generate/cargo-generate/issues/341): https://stackoverflow.com/a/58683367
- A similar github issue: https://github.com/rust-lang/git2-rs/issues/180
I hope this helps, please update us either way! :smiley:
True, I could make it work by temporarily deactivating the libiconv port. Luckily, cargo-shuttle is a static build (this way, against the system libiconv), so I could reactivate the port afterwards and now have a working system again. Thanks a lot for the support!
Now, of course that's not something that you want to tell every interested user. Hence, I also tried LIBGIT2_SYS_USE_PKG_CONFIG=1 cargo install cargo-shuttle
based on the git2-rs issue, but that did not work.
I have a few years of experience with C/C++ build systems (which I rather wish I did not have ;-) ), but I am not able to see what would be the best solution to prevent this problem for everyone. I guess git2-rs was not the worst places to open an issue at, although it is also caused by using MacPorts in the first place.
I'm happy to hear it worked out, and thanks for providing so much info in your issue! This particular problem with cargo and macports is quite old now, so I doubt it's going away anytime soon. Maybe we can provide pre-built binaries in the future so users don't have to run cargo install
.
If you have any other issues don't hesitate to get in touch! We also have an active community on Discord if you'd like to check that out. :slightly_smiling_face:
This worked for me: https://stackoverflow.com/a/58683367
sudo port deactivate libiconv
cargo install cargo-shuttle
sudo port activate libiconv
Thanks @NickLarsenNZ! I am re-opening this for visibility, since this will affect other ARM mac users. I don't think we'll be able to "fix" this any time soon, but installing with binstall or downloading the latest binary from our github releases should work. We might also create a cross-platform install script that fetches the binary from github without the user needing to install binstall.
Thanks @oddgrd! Unfortunately this same issue has essentially been opened several times since the release of the M1. Might make sense to keep it open for a while.
Also adding these terms for search-ability: M1
, M2
and M3
.