MacOS iconv linkage misdetection (also deprecation warnings) #830
Comments
|
On trunk, the same user got |
|
Found a workaround (though not a solution): sudo port deactivate libiconv
cargo build
sudo port activate libiconvThe problem is that there are two instances of libiconv on the system, one that ships with macOS, and one that gets installed by mac ports. The one from macports deliberately has different symbols ( However, the git2-rs's Cmake system finds the macport version of the library, but doesn't check whether it has the symbols it expects (it doesn't), and tries to use it, which fails. It needs to either switch to using these different symbols when linking against that library, or to check skip it because it doesn't have the expected symbols, keep on searching, and find the system library, which does. |
|
Reported upstream to CMake: https://gitlab.kitware.com/cmake/cmake/-/issues/23515 |
nabijaczleweli
changed the title
|
Same issue on macOS 13.1 M2: This doesn't work for me, because I don't use mac ports, and I get a |
|
Did you find any updates about this? Getting the same error. |
|
and // build.rs
fn main() {
println!(r"cargo:rustc-link-search=/opt/homebrew/opt/libiconv/lib");
}fixed it for me. |
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Forwarding nabijaczleweli/cargo-update#176 and nabijaczleweli/cargo-update#186 – MacOS/M1 and previous ports:
Cargo-update has
set, and a user got
The text was updated successfully, but these errors were encountered: