-
Notifications
You must be signed in to change notification settings - Fork 33
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
Add CC and AR variables of compiler name to generated export script #61
Comments
I would like to add also g++ there. Something line this for RISC-V target:
This might help with building dependencies like fltk-rs. @SergioGasquez Might be useful to consider this in context of espup. |
I'm hitting this as well and created this sample repo to test whether I was going crazy: https://github.com/jasta/esp-cc-broken. This prevents me from building lvgl-rs and I'd suspect virtually any other crate that uses the cc (or maybe even bindgen?) crate. |
The solution is definitely not to add CC/CXX though as this is likely to break quite a few other things, but rather we need to figure out how this is supposed to be done nominally so we can build crates that use the cc/bindgen crates without special awareness of embuild. I'd wager the problem exists somewhere in the space of all the random big lists of target triples you see scattered about various tools. For example: https://github.com/rust-lang/cc-rs/blob/main/src/lib.rs#L2883 Right now I can't quite figure out what this is all supposed to be. Rust's story around cross compilation is so new and changing rapidly that it's very hard to tell what is the right thing to do... |
The variable export script currently has this content more or less:
This will currently make
build.rs
-driven cross-compilation impossible since theCC
andAR
are unset and so a crate such ascc
will still use the host's regularcc
andar
commands.Consider this simple
build.rs
:This won't compile properly as it stands right now because of the aforementioned reason. I suggest expanding the exported variables to include all of the cross compilation toolchain tools.
In fact, I wonder why this is not being done and whether I'm missing something here.
Consider this:
Would allow you to compile and link most simple C programs directly and without further hassle. What do you think?
The text was updated successfully, but these errors were encountered: