E0463 on macOS when DYLD_FALLBACK_LIBRARY_PATH is not explicitly handled.

[thomcc]

I get "can't find crate" errors from compiletests that import the library under development unless I explicitly handle DYLD_FALLBACK_LIBRARY_PATH on macOS for linking deps. E.g.

fn link_deps(config: &mut compiletest_rs::Config) {
    config.link_deps();
    // config.link_deps doesn't handle DYLD_FALLBACK_LIBRARY_PATH
    if cfg!(target_os = "macos") {
        let varname = "DYLD_FALLBACK_LIBRARY_PATH";
        let lib_paths = std::env::var_os(varname).unwrap_or_default();
        let mut flags = config.target_rustcflags.take().unwrap_or_default();
        // `flags += lib_paths_flags(&lib_paths).as_str();`
        if !lib_paths.is_empty() {
            for p in std::env::split_paths(&lib_paths) {
                let p = p.to_str().unwrap();
                assert!(!p.contains(' '), "spaces in paths not supported: {}", p);
                flags += " -L ";
                flags += p;
            }
        }
        config.target_rustcflags = Some(flags);
    }
}
// usage is something like:
link_deps(&mut config);
config.clean_rmeta();
compiletest::run_tests(&config);

It's not clear if this is expected or not. Worth noting, DYLD_FALLBACK_LIBRARY_PATH is explicitly set by cargo, so naïvely it makes sense that it should be handled. (For documentation of the different DYLD_ env vars, see man dyld).

[Manishearth]

I'm not actively fixing things here but accepting PRs, so I'm probably not going to investigate this, but happy to accept a PR.

I do know that for tools like this getting the link paths right has always been a pain. compiletest doesn't have great behavior if you have outdated files under target/*/deps and you end up with "multiple candidates" errors.

[thomcc]

I'd submit a PR but it's unclear if the right behavior is to link both, just the fallback path, or what. I suppose at worst this issue can maybe point people in the right direction.