Skip to content
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

Use reponse file on windows and when using gcc #15

Merged
merged 1 commit into from
Sep 8, 2021
Merged

Conversation

N3xed
Copy link
Collaborator

@N3xed N3xed commented Sep 8, 2021

This is to circumvent the command-line length limitation on windows.

Export shlex::join as join_unix_args
Export shlex::quote as quote_unix_arg
Change LinkArgsBuilder::build to return a Result<LinkArgs>
Add cargo::out_dir

This is to circumvent the command-line length limitation on windows.

Export `shlex::join` as `join_unix_args`
Export `shlex::quote` as `quote_unix_arg`
Change `LinkArgsBuilder::build` to return a `Result<LinkArgs>`
Add `cargo::out_dir`
@ivmarkov
Copy link
Collaborator

ivmarkov commented Sep 8, 2021

Looks OK, I'll merge. BTW, these changes probably fall within the perhaps-not-necessary-to-peer-review category, as the API changes are minimal and the rest is Windows specific stuff we have to address anyway.

(Edit: I've submitted a separate issue for the problem below)
Related:
I am half there in figuring out the linkage problems with the native build and the C3 chip:

  • Rust is spitting out a -nodefaultlibs option on the command line, which seems to be kind of like "the default behavior" (but it seems you can control this on a Rust target level, when you define the target)
  • This is somehow preventing the linker from finding the missing intrinsic (__trunctfdf2); if I remove the -nodefaultlibs, it works OK
  • Short term solution: we have a simple workaround in adding a rustflags = ["-C", "default-linker-libraries"] to the [target.riscv32imc-esp-espidf] section in .cargo/config.toml in the relevant binary crate (rust-esp32-std-hello etcetera)
  • Long term solution: we should probably allow the "default libs" behavior on the Rust target level (as in riscv32imc-esp-espidf as well as in all xtensa targets, if it is not allowed there). Reason why I believe this is a correct behavior: I don't see the -nodefaultlibs argument amongst the "native" (cmake) args, which means the native ESP-IDF build is assuming it is NOT set

Unresolved questions/issues:

@ivmarkov ivmarkov merged commit 8e34161 into esp-rs:master Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants