`libiconv` necessary on mac, doesn't link

[boyland-pf]

The mac version of c2rust with dynamic instrumentation enabled only requires libiconv at some point in the build, resulting in the following error.

  = note: Undefined symbols for architecture x86_64:
            "_libiconv", referenced from:
                _git_fs_path_iconv in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
            "_libiconv_open", referenced from:
                _git_fs_path_direach in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
                _git_fs_path_iconv_init_precompose in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
                _git_fs_path_diriter_init in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
            "_libiconv_close", referenced from:
                _git_fs_path_direach in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
                _git_fs_path_iconv_clear in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
                _git_fs_path_diriter_free in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
                _git_fs_path_dirload in liblibgit2_sys-4e72aab137059590.rlib(fs_path.o)
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

This happens on my mac (a Catalina), which has iconv, and won't link libiconv (installed via brew) because it already has iconv which does the same thing.

This post on stackoverflow (https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx) has the best description of the problem that I've found.

Because the compilation is handled by cargo, I don't know how to find a list of all the compilation steps to add --with-libiconv-prefix=<dir> to, or whether this would work.

[fw-immunant]

This seems to impact us because this crate depends on the cargo crate which (transitively) requires the libgit2-sys crate. There are a number of upstream reports related to this issue, but this recent one seems potentially helpful: rust-lang/git2-rs#830

In any case, it does seem that this is an upstream issue and maybe not one we can easily fix ourselves (short of not depending on the cargo crate), and that there are some viable workarounds for users (wrapping our build with port [de]activate libiconv).

[kkysen]

We are planning on no longer depending on the cargo crate soon (see #448). We'll just invoke cargo as an external command and override $RUSTC_WRAPPER, so I think this shouldn't be an issue anymore if we fix that. It's possible we may need cargo for some small querying stuff after that, but I'm guessing it's small enough we can implement it ourselves or use something more detached like cargo metadata.

[kkysen]

Should fixing #448 be prioritized at all? How much of an issue is this for you, @boyland-pf? Fixing #448 would have a bunch of other small benefits as well, but isn't immediately pressing otherwise.

[boyland-pf]

It's a low priority for me.

[kkysen]

@boyland-pf, can you confirm if this has been fixed now after #554 landed?

[boyland-pf]

Yes, it's been fixed, instrumentation can run on mac.