rustc-link-search parameters are not propagated to dependent crates

[djmarcin]

I'm trying to use the https://crates.io/crates/sentry-contrib-native crate which in turn depends on https://crates.io/crates/sentry-contrib-native-sys which has a build.rs that adds a rustc-link-search param. This parameter is correctly present in bazel-out/k8-fastbuild/bin/external/raze__sentry_contrib_native_sys__0_3_1/sentry_contrib_native_sys_build_script.linkflags but compilation eventually fails because the rust_binary that transitively depends on sentry-contrib-native-sys does not pick up the flag -L=${pwd}/bazel-out/k8-fastbuild/bin/external/raze__sentry_contrib_native_sys__0_3_1/sentry_contrib_native_sys_build_script.out_dir/lib, but it does seem to pick up the -lsentry, -lcrashpad_client, etc which can't be founds with out the -L flag.

It seems like this flag needs to be propagated up through transitive dependencies to the target that gets linked.

[illicitonion]

We used to propagate these transitively, and #448 changed that...

@djmarcin - could you put together a minimal repro case of this not working?
@dae - any thoughts?

[dae]

This is not an area I know well, so I can only guess here - but maybe rustc-link-search should be propagated transitively, but not rustc-link-lib? If that is the case, it will be a little tricky, as currently cargo_build_script_runner lumps them all in together into link_flags.

https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname

[djmarcin]

Here's an example with the sentry crate https://github.com/djmarcin/sentry-repro. It could probably be reduced more, but I'm not certain why other sys crates don't seem to be showing the same issue.

The example also builds with cargo, and when building with -vv you can see that cargo does seem to pass the rustc-link-search up to the bin crate (although interestingly, it does not pass the -lsentry -lcrashpad_client etc that rules_rust is passing to the top level rust_binary crate -- these are only passed to the sys crate).

I suspect there may be something amiss with how the sentry-contrib-native crate is being compiled / linked against the sentry-contrib-native-sys crate, since the missing symbols seem to come from sentry-contrib-native code.

[djmarcin]

I was able to get this to succeed by patching the sentry-contrib-native-sys crate to emit link instructions like cargo:rustc-link-lib=static=sentry instead of cargo:rustc-link-lib=sentry, although it seems like it should work either way since it works in cargo.

My uninformed guess is that the rlib has some embedded info that it needs the "sentry" library to be linked and cargo passes along the link path so when rustc attempts to link "sentry" it finds it on the propagated link path, whereas because bazel is not propagating the link path, it's not found. Does this sound right?