Anyone using rpath in Cargo profiles?

josh · 2018-03-29T08:38:11.717Z

Something that came up in the Cargo meeting at the Rust All-Hands: is anyone using the rpath functionality in Cargo profiles?

This seems like something that doesn’t quite fit in Cargo profiles; rather, if needed at all, it seems like something specific to a specific user of a crate rather than all users of a crate. So, to the extent it makes sense, it seems like something that ought to be defined on a build-by-build basis (or in user-specific cargo configuration or command-line options) rather than as a profile.

Does anyone have a use case for this mechanism? If so, could you talk about what you’re doing with it, and how that might interact with the notions above?

cc @aturon

SimonSapin · 2018-03-29T09:31:35.133Z

Firefox has rpath = false but it looks like that’s the default. (Was it always?)

Mark_Simulacrum · 2018-03-29T14:13:09.845Z

The authors whose crates or GH repos are seen/tested by Crater and have rpath = true in their tomls are probably good to hear use cases from:

polyline-ffi cc @urschrei
rdp cc @urschrei
lonlat_bng cc @urschrei
gst cc @ehiggs
polylabel cc @urschrei
diecast cc @blaenk
slice-deque cc @gnzlbg

If you know of anyone else who uses/cares about rpath in toml files please let us know as well!

gnzlbg · 2018-03-29T15:03:54.349Z

For slice_deque I am pretty sure this is a copy&paste error. It is only used in [profile.dev], and I probably just copied all [profile.dev] options form somewhere (the manifest format reference maybe?) and edited only some of them. rpath = true just rode along with those.

urschrei · 2018-03-29T15:46:21.505Z

I specified it because back when I was first making dynamic libraries (a cdylib) available to Python modules via Cython (Summer 2016), so they could be built as wheels, the dynamic libraries produced by rustc didn’t include rpath info by default. See here: https://stackoverflow.com/a/37757642/416626.

I don’t really know enough about rpath to comment, but it always struck me as odd that it wasn’t included by default, especially when specifying that your crate type is cdylib.

josh · 2018-03-30T07:34:56.826Z

See https://wiki.debian.org/RpathIssue among other things. RPATH breaks various things that distributions such as Debian want, including the ability to move libraries around.

urschrei · 2018-03-30T11:00:08.267Z

Oof. Well, as long as it remains available via RUSTFLAGS…

josh · 2018-03-30T11:27:48.260Z

It can and should absolutely remain available via any build-local mechanism, specified by the person building the crate for their environment. I’m purely arguing that it shouldn’t be part of Cargo.toml.

urschrei · 2018-03-30T13:37:21.032Z

I’ve just switched one of my projects over to RUSTFLAGS (it works with cross too, which was a concern), and the Python build seems OK with the new lib, so +1 from me.

blaenk · 2018-04-06T16:58:37.257Z

Please feel free to disregard the use of rpath in my crate (diecast). IIRC it was something I was playing around with locally and I must have mistakenly published it. Thanks for bringing it to my attention.

urschrei · 2018-04-07T18:38:06.129Z

So I’m the only person on the planet (well, apart from the crates that crater knows nothing about. The Darkweb of crates, essentially) who intentionally used this feature? I feel very special.

ehiggs · 2018-04-17T11:35:36.108Z

This is also the case with rust-gst. I’ll push a new version with it removed.

system · 2019-03-25T08:29:59.201Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.