0.10.0 changes libdir unexpectedly

[cpu]

Hi folks,

Over in rustls-ffi we have a GitHub workflow and Makefile that tests building a .so/.pc for rustls and then building our demo applications with it + pkg-config.

I noticed that after the job switched to installing the just-released 0.10.0 that it started to fail with output indicating pkg-config isn't finding the .pc file anymore. Switching the job to use 0.9.32 fixed the build, so I'm fairly confident that something about rustls-ffi and cargo-c 0.10.0 is at fault.

Confusingly, when I reproduce the build locally on my NixOS system with cargo 1.81.0-nightly, pkg-config 0.29.2 and cargo-c 0.10.0 everything seems to "just work" (?). The .pc file produced in my local testing seems identical between versions (with the exception of libdir changing from libdir=${exec_prefix}/lib (0.9.29) to libdir=${prefix}/lib (0.10.0) (but since prefix == exec_prefix in the .pc this change doesn't feel particularly meaningful).

Do you have any thoughts or ideas for next debugging steps? Thanks!

[cpu]

I think it's perhaps specific to using cargo-c 0.10.0 on a Debian-like system, which would help explain why I can't reproduce locally on my non-Debian system.

Adding more debugging to CI I see that cargo cinstall --locked --release --prefix=/tmp/librustls using 0.10.0 is emitting a directory structure like:

/tmp/librustls
/tmp/librustls/lib
/tmp/librustls/lib/x86_64-linux-gnu
/tmp/librustls/lib/x86_64-linux-gnu/librustls.so
/tmp/librustls/lib/x86_64-linux-gnu/librustls.so.0.13.0
/tmp/librustls/lib/x86_64-linux-gnu/pkgconfig
/tmp/librustls/lib/x86_64-linux-gnu/pkgconfig/rustls.pc
/tmp/librustls/lib/x86_64-linux-gnu/librustls.a
/tmp/librustls/include
/tmp/librustls/include/rustls.h

where-as using 0.9.32 produces:

/tmp/librustls
/tmp/librustls/lib
/tmp/librustls/lib/librustls.so
/tmp/librustls/lib/librustls.so.0.13.0
/tmp/librustls/lib/pkgconfig
/tmp/librustls/lib/pkgconfig/rustls.pc
/tmp/librustls/lib/librustls.a
/tmp/librustls/include
/tmp/librustls/include/rustls.h

So perhaps our PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig needs to change to PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu/pkgconfig.

[cpu]

So perhaps our PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig needs to change to PKG_CONFIG_PATH=$PREFIX/lib/x86_64-linux-gnu/pkgconfig.

that, and adjusting the LD_LIBRARY_PATH when invoking the built examples seems to do the trick, but requires further bifurcation of the Ubuntu vs MacOS builds (to conditionally add the x86_64-linux-gnu directory).

I think this change was introduced in 1d3c7d3 - should it have broken our workflow like this? Perhaps the approach we're using was overly brittle to begin with?

[lu-zero]

We got the request to do that and I bumped the version exactly because it will change the behaviour on debian-like distributions.

The simple way to undo it is to pass --libdir explicitly. I hope it helps, I guess I should add to the README the expectation changes :/

[cpu]

The simple way to undo it is to pass --libdir explicitly.

That sounds like a nicer workaround, thank you!

I guess I should add to the README the expectation changes :/

That would be great 👍 I think it would have helped me figure out the issue a little bit faster.

I've updated the issue title to reflect this isn't really a regression so much as a breaking change I didn't expect. I think we can close this out. Thanks for letting me rubber duck debug in your issue tracker :-)

[lu-zero]

I'm sorry it got you by surprise, thank you for reporting it!