-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crates dependent on libgit2-sys
fail to link when libiconv
is installed via MacPorts
#672
Comments
This happens because of the name mangling that iconv does when installed in "third party" mode, such as via MacPorts. Symbols like
Your presumption of why the issue happens seems to be correct — because there's no However, the root cause seems to be that the headers from the system iconv are still being used. In #ifndef LIBICONV_PLUG
#define iconv_open libiconv_open
#endif ... which would cause the correct symbols to be used. So if we can get |
And, indeed, |
Or perhaps |
Assume you mean library search paths, since the problem seems to be that the library from /opt/local is being picked up whereas the headers from /opt/local are not. and indeed, the compiler is being invoked with |
I'm experiencing the build failure described in this bug, but I'm using macOS Catalina 10.15.7 (not 11) on an x86_64 machine. Would this be the same bug or different? |
@kpreid the symptoms described here would come about any time there is a mismatch between which iconv library is being used and which headers are being used. It's easier for that to happen on 11 because there's no You need to ensure that if system (Apple-provided) iconv headers are used, then system iconv is linked, and if MacPorts iconv headers are used, MacPorts iconv is linked. |
Hi. Same here. I have macos ventura.
|
Not sure if this is thought to be a rust/libgit2-sys or macports problem, but I just encountered it compiling a rust project exactly as described above. I have macports, |
How to reproduce:
libiconv
using MacPorts:sudo port install libiconv
Note: many common ports depend on
libiconv
so it is usually installed indirectlylibgit2-sys
e.g.cargo
:git clone https://github.com/rust-lang/cargo.git cd cargo cargo build
Expected result:
The crate builds successfully
Actual result:
cargo
is cloned to/Users/david/Code/cargo
arm64
architectureAdditional notes:
This is a reopening of #180 which has started occurring again on macOS 11, due to the following change:
This presumably causes the
libiconv
from MacPorts to take priority over the built-in one, as the built-in one is no longer provided in/usr/lib
(which is prioritised over/opt/local/lib
).The text was updated successfully, but these errors were encountered: