Skip to content

#[link_args] is not propagated from libraries to binaries #36176

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
whitequark opened this issue Aug 31, 2016 · 4 comments
Closed

#[link_args] is not propagated from libraries to binaries #36176

whitequark opened this issue Aug 31, 2016 · 4 comments

Comments

@whitequark
Copy link
Member

To reproduce:

// foo.rs
#![feature(link_args)]
#[link_args = "-Wl,-just_die"]
extern {}
// main.rs
extern crate foo;
fn main() {}

Build with:

rustc foo.rs --crate-type lib
rustc main.rs -L .

This successfully builds (and it shouldn't, if it would pass the -Wl,-just_die). (--verbose is not usable here because of #36175). If I replace #[link_args] with e.g. #[link(name = "just_die")] then the linker invocation fails, so I believe this is a bug with link_args.

@whitequark
Copy link
Member Author

My particular use case is a library that includes DWARF unwinding info that crashes ld64, so I need to be able to include #[link_args = "-Wl,-no_compact_unwind"] in the library to work around that, otherwise it has to be manually inserted into every binary crate.

@japaric
Copy link
Member

japaric commented Sep 1, 2016

How this propagation mechanism should work is an unresolved question of the issue that's tracking the stabilization of this link_args feature. cf. #29596 (comment)

@alexcrichton
Copy link
Member

This is an intentional design decision of #![link_args], and is one of the reasons it's not generally suitable for passing linker arguments. This "feature" has basically always been slated for deprecation/removal.

@whitequark
Copy link
Member Author

@alexcrichton ack, closing then. I assume that once lld gets integrated into rustc this goes away / gets turned into proper attributes, though the situation might be worse for thrid-party Rust compilers...

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants