Skip to content

Please propose a way to add / remove flags from a compilation step #15054

New issue

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

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

Already on GitHub? Sign in to your account

Closed
sylvestre opened this issue Jun 20, 2014 · 9 comments
Closed

Please propose a way to add / remove flags from a compilation step #15054

sylvestre opened this issue Jun 20, 2014 · 9 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

Comments

@sylvestre
Copy link
Contributor

In the context of packaging Rust, we might need to add or remove CFLAGS/CXXFLAGS during compilation time.
AFAIK, they are currently hardcoded (and computed) in the binary downloaded during the first step of the build.

For example, the full command line on my system is this one:

rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin/rustc
error: linking with `cc` failed: exit code: 1
note: cc '-m64' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-o' 'x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin/rustc' 'x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin/rustc.o' '-lmorestack' '-nodefaultlibs' '-Wl,--gc-sections' '-Wl,--as-needed' '-Wl,-O1' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lnative-1fb5e2c0-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lrustc-d252d482-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lflate-92afea7e-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lgetopts-c94737d1-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lsyntax-555559ea-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lterm-4e4945a5-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-ltime-4bb3739b-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lserialize-0352aab7-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-llog-cd053230-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lsync-305341d2-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lfmt_macros-5125f3bd-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lgraphviz-7b3cf89d-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-larena-063bff73-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lcollections-d412c0c4-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-ldebug-1e940314-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lstd-59beb4f7-0.11.0-pre' '-L' '/home/sylvestre/dev/mozilla/rust/.rust' '-L' '/home/sylvestre/dev/mozilla/rust' '-Wl,-Bdynamic' '-lpthread' '-lffi' '-ltinfo' '-ldl' '-lm' '-lstdc++' '-lrt' '-ldl' '-lpthread' '-lgcc_s' '-lpthread' '-lc' '-lm' '-Wl,-rpath,$ORIGIN/../lib' '-Wl,-rpath,/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib' '-lcompiler-rt'
note: /usr/bin/ld.bfd.real: cannot find -lcompiler-rt
collect2: error: ld returned 1 exit status

error: aborting due to previous error
/home/sylvestre/dev/mozilla/rust/mk/target.mk:172: recipe for target 'x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/bin/rustc' failed

In this case, I would need to add a -L to point to the correct compiler-rt library (I know there are workaround for this, it is just an example). Adding or removing flags passed to the linker is also a common usage while packaging software.

@alexcrichton
Copy link
Member

When using our makefiles, you can use the RUSTFLAGS variable to pass extra flags to all invocations of rustc. Does that suffice for your use case?

@sylvestre
Copy link
Contributor Author

Well, no, unfortunately. I need to be able to remove flags... More over, I should be able to set the right flags when needed. Not as a global declaration.

@sylvestre
Copy link
Contributor Author

Potential solution: what about having a text file with the build flags used? The rust compiler could use that file and we, packager, could update it.

@steveklabnik
Copy link
Member

Triage: @brson has been working on a lot of packaging stuff, but I believe we still only have RUSTFLAGS, without a way to remove flags.

@brson
Copy link
Contributor

brson commented Feb 5, 2016

Are there any standard ways to remove flags in a build system ala CFLAGS? It's not something I've ever seen before.

It would be easy to make all these settings overridable wherever they aren't, though I'm not sure that is powerful enough.

@steveklabnik
Copy link
Member

I think that systems often give you both "yes" and "no" flags, and the last one wins. So you can append to CFLAGS with -fno-foo and even if -ffoo appears before, it will work.

My brain may have also just entirely made this up.

@koobs
Copy link
Contributor

koobs commented Feb 6, 2016

FWIW, all user supplied *FLAGS & VARIABLES should be honoured, this includes CC, {C,L,PP,XX}FLAGS, LIBS et al. That is, they should be the last variable on any assignment line, and never appended to.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 21, 2017
@Mark-Simulacrum Mark-Simulacrum added T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) and removed A-build labels Jul 29, 2018
@Mark-Simulacrum
Copy link
Member

I believe we mostly respect environment-variable set flags today; presumably that's sufficient for this use case? It's still relatively difficult to set different flags for different stages of compilation, but I would hope that it's not (ever) necessary to do so. If this is still a problem a specific reproducible example or want would be good to have.

@sylvestre
Copy link
Contributor Author

yeah, we (debian) don't need that anymore

lnicola pushed a commit to lnicola/rust that referenced this issue Jun 19, 2023
…do-not-transform-const-params, r=lowr

fix: implement missing members doesn't transform const params and default types

Fixes rust-lang/rust-analyzer#13363
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

No branches or pull requests

6 participants