cargo install does not respect LDFLAGS

Question

cargo install does not respect LDFLAGS

Closed this issue 6 years ago · 9 comments

When the building system has LDFLAGS set, cargo / rustc should respect the system's LDFLAGS

Answer 1 · 2017-02-13T20:09:49.000Z

Right now Cargo respects RUSTFLAGS but that's the only env var for passing flags down. What sort of LDFLAGS are you thinking of?

Note that the exact linker that the compiler invokes isn't guaranteed to not change over time, so there's not always a valid interpretation of LDFLAGS even if it exists.

Answer 2 · 2017-03-02T15:33:06.000Z

Sorry for the delay, @sergiusens would be able to go into more depth on the specifics. The goal was to get a Rust project built into a Snap with Snapcraft but the built binary wasn't using the correct libraries

Answer 3 · 2017-03-05T17:09:46.000Z

where are RUSTFLAGS documented? The linker flags we want to pass on are runpath/rpath related as well as the one that sets the linker loader the binary should use.

Answer 4 · 2017-03-06T16:27:35.000Z

@sergiusens it's documented here

Answer 5 · 2017-04-10T14:27:58.000Z

expanding a bit on this, some issues we're having with getting this working: https://gist.github.com/ChrisMacNaughton/a81233e05995013ebb9a0c333c157b76

Answer 6 · 2018-09-20T17:40:24.000Z

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

Is this still relevant?
If so, what is blocking it?
Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

Answer 7 · 2018-10-20T18:29:26.000Z

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!

Answer 8 · 2020-12-09T21:13:54.000Z

A simple question related to this issue.

I need to send the options -Wl,-rpath,/data0/opt/miniconda3/envs/env_hg_rust/lib -Wl,-rpath-link,/data0/opt/miniconda3/envs/env_hg_rust/lib to the linker.

Is it possible to do that with an environment variable (I don't control the cargo or rustc command)?

I can use RUSTFLAGS for things like -L/data0/opt/miniconda3/envs/env_hg_rust/lib but what about more advanced linker options?

Answer 9 · 2022-04-30T00:32:00.000Z

I'm running into a related issue - we have --coverage (amongst other things) set in our CFLAGS. For some build script builds this is resulting in link errors such as undefined symbol: llvm_gcov_init because --coverage isn't also being passed to the link step as well. Leaving aside the question of whether or not CFLAGS should be having an effect on a build script build, there are several similar flags which will cause problems if used in CFLAGS (which usually applies because it's consumed by something like cc::Build in a build script) but not in LDFLAGS, for example -fopenmp or -flto. Particularly in a context where cargo is being used as one step in a larger build process, honoring CFLAGS but not LDFLAGS can cause all kinds of problems.