pcsc-sys lacks rpath support because of old pkg-config-rs pin and no environment variable override

[riastradh]

pcsc-rust/pcsc-sys/Cargo.toml

Line 17 in 9f5c3a9

pkg-config = "0.3.9"

When the libpcsclite.so library, which pcsc-rust is linked against, lives in a non-default library directory, such as /opt/local/lib or /usr/pkg/lib, it is not enough for pcsc-rust to be built with -L/opt/local/lib -- that only tells the build-time linker where to find the library; it doesn't tell the run-time loader where to load the libpcsclite.so.N shared library file from. This requires specifying rpath with -Wl,-R/opt/local/lib or -Wl,-rpath,/opt/local/lib, which instructs the build-time linker to bake that path into the resulting executable or library so the run-time loader knows where to find the libraries it depends on.

(Note that the -L and -R arguments may be different -- for example, when cross-compiling, one might use -L/home/riastradh/obj.powerpc/destdir/opt/local/lib -Wl,-R/opt/local/lib.)

pkg-config-rs, used by pcsc-sys to find libpcsclite.so build options, sprouted support for rpath last year to take advantage of .pc files with rpath options, but only in version 0.3.25. The current version is 0.3.26. pcsc-sys is pinned to 0.3.9, which just silently ignores any rpath options in .pc files.

There is also no environment variable to pass through compiler or linker options explicitly when overriding pkg-config, which could be used to specify an rpath manually.

[bluetech]

The pcsc-sys Cargo.toml says pkg-config = "0.3.9" which means pkgs-config >=0.3.9, <0.4.0 (see here). It's not pinned to 0.3.9.

[riastradh]

Thanks, sorry for the noise. Evidently the rpath is not getting passed through for some other reason, then, and I need to investigate further.

[riastradh]

The original issue I tripped over was that the authenticator-rs test program, from the Crote/nfc branch, lacked the correct rpath.

Do you by any chance know how downstream programs that use rust-pcsc are supposed to learn about the rpath that pcsc-sys determined from pkg-config? They presumably learn about -lpcsclite and -L${prefix}/lib, because the executable ends up linked against libpcsclite.so.1, but the rpath has been lost along the way -- perhaps something passes some linker arguments through but not others?

[bluetech]

Maybe try building with cargo build -vv which would hopefully show the rustc invocation (didn't try this exactly, but there's surely a way to do this), then you can examine the linker flags.

[Fethbita]

@bluetech I am facing a similar issue in an alpine docker image. As you can see here https://github.com/Fethbita/emrtd/actions/runs/11203271682/job/31140323550#step:6:262 the build works but testing fails for some reason with the error:

  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lpcsclite: No such file or directory

[bluetech]

@Fethbita According to https://doc.rust-lang.org/reference/linkage.html#static-and-dynamic-c-runtimes IIUC this musl target is using static linking by default. If you want to link pcsclite, you'll need to switch to dynamic linking runtime.

[Fethbita]

Yes, you were right @bluetech. Thank you! I didn't realize this was the issue. Now all of the dependencies are dynamically linked. To solve this issue, I had to define two environment variables for cargo test:

RUSTFLAGS="-C target-feature=-crt-static" RUSTDOCFLAGS="-C target-feature=-crt-static"

or define the following in the .cargo/config.toml (or for older cargo versions .cargo/config) file:

rustflags = [
    "-C", "target-feature=-crt-static",
]

rustdocflags = [
    "-C", "target-feature=-crt-static",
]

Maybe we can mention this in the readme.