Anyone using rpath in Cargo profiles?

1

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

2 Likes
2

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

1 Like
3

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:

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

2 Likes
4

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.

1 Like
5

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.

1 Like
6

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.

2 Likes
7

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

1 Like
8

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.

4 Likes
9

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.

2 Likes
10

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.

2 Likes
11

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.

3 Likes
12

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

2 Likes
13

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