-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Support armv7l-hf #13738
Support armv7l-hf #13738
Conversation
This seems odd to single out only |
Yeah, I felt exactly the same way. Thought on how to generalise it are very welcome- I have only a very minimal ARM test environment. I can apply all of these changes to arm, my hesitation stems from the assumption that it's presently working on for other arm platforms. Should I just apply it to all arm and see what breaks/who yells at me? |
Having given this a bit of thought, my two main goals are:
To this end, I want to update the configure script to default arm builds to a pretty sane set of defaults that will probably work everywhere and add some flags to specialize, as well as an |
For reference, I have gone through three secondary OSes on my Android + Something Else device:
|
I guess another option is to leave the defaults as is, and add a 'sniff arm' option that shells out to another (bundled) tool that does it's best to work out a reasonable set of options for the thing that you're on. |
I'm worried about this patch singling out one specific ARM architecture, when the architecture itself has little to do with the fix. It seems the real issue here is that the compiler doesn't accept an |
@alexcrichton Could we land this as is and then gather more data later? Rather than aiming for perfection immediately, I believe that landing this is reasonable; we’ll find out how the situation lies and can make further changes later. It’s not like it’s a big change. |
Why don't you simply remove -m32 from all ARM builds? |
I'm open to nuking -m32 from all ARM builds if noone objects (we can deal with aarch64 later when someone needs it?) |
AArch64 will hopefully be specified by a different -arch or -triple, not -m32. I know it's that way with Clang, but I'm not sure about GCC. |
Cool. I'm going to update this PR. |
First off, thanks! I've been meaning to get building on arm work (in a non-adhoc manner). I think it'd be better to just remove all the case "$CFG_C_COMPILER" in
("ccache clang")
...
;;
("gcc")
...
;;
# etc
esac
case "$CFG_CPUTYPE" in
(x86*)
LLVM_CXX_32="$LLVM_CXX_32 -m32"
LLVM_CC_32="$LLVM_CC_32 -m32"
;;
esac That way we wouldn't have to have all those comparisons against Also, for the libcpp stuff, I think it'd be better if there was a flag like It'd also probably be fine to just squash those commits into one. With all that, r=me. |
I just updated this PR. It's going to take a long time to test it properly (my arm machine is a chromebook.. rust builds take their time) and unfortunately this doesn't get it to the point where a simple: ./configure
make does the right thing, but it gets it much, much closer. |
This was required to get ./configure to work on my armv7 test machine. I haven't found anything sane to feature gate `hf` on that's pokable from the context of the configure script. It also seems that gcc doesn't work on armv7 by default (rust wants to pass it `-m32` which isn't supported), would it be preferential to make the default `--enable-clang` on arm, or remove the `-m32` flag on that platform?
fix: Increase token limit of proc macro Fixes rust-lang#13738 [The swc project](https://swc.rs) has lots of type definitions, and the current limit is too low for the ECMAScript/CSS visitors. [rustdoc](https://rustdoc.swc.rs/swc_ecma_visit) --- With this fix, the rust-analyzer shows trait-related actions. <img width="1840" alt="image" src="https://user-images.githubusercontent.com/29931815/206839269-d7a04589-7dba-449b-ad0b-1f69d52bd039.png">
This was required to get ./configure to work on my armv7 test machine.
I haven't found anything sane to feature gate
hf
on that's pokable from the context of the configure script.It also seems that gcc doesn't work on armv7 by default (rust wants to pass it
-m32
which isn't supported), would it be preferential to make the default--enable-clang
on arm, or remove the-m32
flag on that platform?