There's a crate pcsc (https://github.com/bluetech/pcsc-rust) which wraps a C library, pcsclite, and discovers how to against it -- the appropriate linker options -- with pkg-config.

There's another crate authenticator-rs (https://github.com/mozilla/authenticator-rs) which has a branch to add NFC/smartcard transport for FIDO (https://github.com/mozilla/authenticator-rs/pull/114) using the pcsc crate.

When I build the authenticator-rs example program from the branch with cargo build --example main, it gets linked against libpcsclite.so.1, so presumably the linker arguments -L/path/to/lib -lpcsclite made it through from the pcsc build to the authenticator-rs build -- but the executable is missing /path/to/lib from its rpath, so it doesn't run, because runtime loader doesn't search /path/to/lib by default.  Presumably the additional argument -Wl,-R/path/to/lib got lost somewhere along the way.

Does anyone know how a crate like pcsc transmits this linker argument information through to dependent crate builds?  Where could the rpath be getting lost?  Are there any files I should look at under target/ to investigate this?

Looks like the answer might be https://github.com/rust-lang/cargo/issues/9554 (which I somehow already had open in another tab, and no memory of getting there!).

Looks like a workaround might be DEP_THEDEPNAME_LINK_FLAGS, according to the comment https://github.com/rust-lang/cargo/issues/9554#issuecomment-857882964.  Is there documentation for this mechanism? Kinda hard to search for.

Looks like maybe that documentation is here https://doc.rust-lang.org/cargo/reference/build-script-examples.html#using-another-sys-crate, but I'm not sure how to use it; I don't see any DEP_PCSC_* environment variables when I run authenticator-rs's build.rs, by adding

    for (key, value) in std::env::vars_os() {
        println!("hack:{}:{}", key.to_str().unwrap(), value.to_str().unwrap())
    }

and examining the output file.  Does the pcsc crate have to do something to opt into sharing the linker arguments it discovered from pkg-config?

The rpath flag appears in what I believe is the output from pcsc-sys build.rs:

$ grep Wl,-R target/debug/build/pcsc-sys-d6a5c9a18a385205/output
cargo:rustc-link-arg=-Wl,-R/pkg/2022Q4/lib

However, it doesn't appear anywhere in cargo build --verbose output.  I see this in the arguments to rustc:

... --extern pcsc=/home/riastradh/crypto/webauthn/authenticator-rs/ctap2-2021/target/debug/deps/libpcsc-3fbd27ec27a1cbe5.rmeta ... -L native=/pkg/2022Q4/lib

when compiling authenticator, and

... --extern pcsc=/home/riastradh/crypto/webauthn/authenticator-rs/ctap2-2021/target/debug/deps/libpcsc-3fbd27ec27a1cbe5.rlib ... -L native=/pkg/2022Q4/lib

when compiling main.  But I don't see any -Wl,-R in the output or in libpcsc-3fbd27ec27a1cbe5.rmeta or in libpcsc-3fbd27ec27a1cbe5.rlib.

But I also don't see -lpcsclite anywhere in this output or in the files, so I suspect there's something else going on behind the scenes that cargo build -vvv isn't revealing.

I can confirm with ktrace that rustc is passing -L /pkg/2022Q4/lib and -lpcsclite to cc as a subprocess, but not -Wl,-R/pkg/2022Q4/lib.

The only file under target/ in which -Wl,-R/pkg/2022Q4/lib appears is target/debug/build/pcsc-sys-d6a5c9a18a385205/output.

If I put println!("cargo:rustc-link-arg=-Wl,-R/pkg/2022Q4/lib") in authenticator-rs build.rs, then it gets included.

If I understand correctly, https://github.com/rust-lang/cargo/issues/9554 means that it is on purpose that pcsc-sys's rustc-link-arg is not passed through automagically to authenticator-rs.  The comment about DEP_PCSC_* suggests that there is supposed to be a mechanism for authenticator-rs to explicitly ask for it to be passed through.  But I don't know how to make that environment variable work.  Does pcsc-sys have to do something to expose it to authenticator-rs build.rs so the latter can ask to use it?

I wonder whether lines of the form cargo:rustc-* are excluded from these build.rs metadata environment variables?

It looks like the DEP_{dependency}_{variable} environment variables are generated here:
https://github.com/rust-lang/cargo/blob/99ad42deb4b0be0cdb062d333d5e63460a94c33c/src/cargo/core/compiler/custom_build.rs#L360-L364
But there's a lot of abstraction in the way of which variables are included.  It comes out of a combination of build_script_outputs, dep.unit.mode.is_run_custom_build, cx.get_run_build_script_metadtaa, and whatever else those call; I haven't looked deeper into those.

Is there an easy way to test building authenticator-rs against a locally modified pcsc-sys?

Answer: roughly yes, with the path = ... option in the Cargo.toml dependencies block.

OK, there are two problems.
1. cargo passes through something like cargo:rustd-link-arg as DEP_PCSC_RUSTD_LINK_ARG but does not pass through cargo:rustc-link-arg as anything.
2. Variables passed through that way by pcsc-sys to pcsc are not transitively passed through to authenticator-rs.

Remains unclear to me why variables defined by pcsc-sys are passed through as DEP_PCSC_* and not as DEP_PCSC_SYS_*.

3. Not only does it not pass variables through transitively, it only passes them through to direct dependencies of packages that link against native libraries: https://github.com/rust-lang/cargo/issues/3544