Build fails on macOS Sierra (10.12.6) due to undefined symbols #263
Comments
|
Do you have a custom build of libiconv somewhere perhaps? It looks like |
|
Not that I'm aware of. I'm running this in an up-to-date homebrew environment. I have a another mac I can try it on. |
|
Sorry I'm not really sure what's going on here :( |
|
I'm getting this same error when trying to compile exa (see ogham/exa#353) on macOS 10.13. Interestingly, cloning git2-rs and running |
|
Oh now that's interesting. |
|
Adding either of the |
|
Curiouser and curiouser. The 3 missing symbols ( rv = iconv(ic->map, &nfd, &nfdlen, &nfc, &nfclen);So why is it trying to link against the 32-bit |
|
Great, it's finding Though this doesn't explain why adding the ssh or https features fixes the problem. |
|
At this point I'm going to stop debugging. I just ran In any case, since I've now worked around the problem locally, I can't do anything else on this front. |
|
I hit the same error and I found it was because there's another copy of It's a bit annoying that there are so many different places to check on macOS. |
|
I got the same error trying to |
|
I faced the same situation for
Does anyone solve this issue by another way? |
|
Did you search for |
|
Thanks for the advise. Yeah I'd searched by find command for whole directories. I have no idea how to fix it now. (Sorry for missing my logs. I'm using another PC without the problem.) |
dyld: Symbol not found: _iconv dyld: Symbol not found: _iconv Referenced from: /usr/lib/libcups.2.dylib Expected in: /sw/lib/libiconv.2.dylib in /usr/lib/libcups.2.dylib Referenced from: /usr/lib/libcups.2.dylib Expected in: /sw/lib/libiconv.2.dylib in /usr/lib/libcups.2.dylib some context in https://github.com/alexcrichton/git2-rs/issues/263
|
I've been having this problem for a while and still hasn't been able to find a stable configuration for getting around it. The main problem is that I'm not sure what's the supported configuration on macos. Specifically, is |
|
It's expected that git2-rs builds its own copy of libgit2 and doesn't use the system version, as the system version is likely incompatible |
|
I think this has likely long since been fixed, so I'm going to close. |
|
For what it is worth, if people still search for this issue (as I have), here is what worked for me: In my It may suck to end up looking in that lib first, even for things that don't depend on -liconv, but I'm happy to have the commuter do a tiny bit of extra build for each build then for me to figure out which cases this is needed in. I've also filed a MacPorts request for a libiconv-select to help deal with the problem as it interacts with other things beyond rust. |
|
I think this should be re-opened as I've also encountered the issue when attempting to install Setting |
|
I also think this should be reopened. I'm hitting the same problem trying to build |
|
Ehi @kencu. By your you mean me specifically or |
|
Hi @rubendibattista -- I realized the comment was just a duplicate of one above, where this was already identified. |
|
@kencu Sorry if I don't follow, but I don't understand why changing the linker options is needed. My questions:
|
|
On purpose, the libiconv headers and libraries in /usr and /opt use different sets of symbols: This is specifically done by libiconv to prevent you from using one set of headers with the other (non-matching) library. So if your build is somehow set up to find the headers in one place, but link the library from the other place, you get an error that you are supposed to fix in your build system. I suspect that way back in the day the libiconv people received a bazillion bug reports that in the end were caused by mismatched header/library set, and said to themselves "We'll fix this once and for all!". It's a Good Thing, all in all, although it can be frustrating to actually fix your build system. For MacPorts, I suspect the fact that want to use openssl (in /opt/local) but not libiconv (but it is also in /opt/local) is the source of our troubles. libiconv is not tucked away, the header is right out there: and so we pick that header up when we don't actually want it. |
|
we could hack in a blocker -- some define we add to that, if defined, would stop our |
|
Oh, and you may wonder why this only happens with MacPorts and not with the main competition: the main competition puts everything in /usr/local/include and /usr/local/lib, and because those locations are always automatically searched by the compiler no matter what the build system does or does not do, the errors never show up there, as there is always a match between header and library. |
|
@kencu This is all very cool and correct IMO. But... Is it then that Don't know if it's a specific |
Summary: eagerepo -> metalog -> git2 -> libgit2-sys -> libgit2 conflicts with edenfs' non-Rust libgit2 dependency. Rust git2 crate does not seem to provide a way to depend on specified libgit2. Quote rust-lang/git2-rs#263 (comment): > It's expected that git2-rs builds its own copy of libgit2 and doesn't use the > system version, as the system version is likely incompatible It also seems non-trivial to make buck C++ use the libgit2 frm `libgit2-sys` crate. Let's just avoid depending on eagerepo from edenapi directly for now to solve the issue. This basically revives D27948369 and D27951632. Reviewed By: xavierd Differential Revision: D28243784 fbshipit-source-id: 0c38c20c2d3a80c550732129da572fe26a229799
Solution found here: rust-lang/git2-rs#263 (comment)
Building git2-rs failes to build on my system, a macOS Sierra 10.12.6. (However, I see that travis correctly builds the same checkout)
Some system information:
The cli-output:
The text was updated successfully, but these errors were encountered: