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

add prefixes for x86 to support cross-compiling from non-x86 targets #621

Merged
merged 1 commit into from Oct 6, 2021

Conversation

infinity0
Copy link
Contributor

otherwise cross-compiling from arm64 -> i686 fails, e.g. http://crossqa.debian.net/build/rustc_1.49.0+dfsg1-1_i386_20210907094750.log

@infinity0
Copy link
Contributor Author

The linux32 build is failing I think because it is relying on a x86_64-*-gcc to have multilib and using that instead of i686-linux-gnu-gcc (which is what one would use in a general cross-compiling $host-to-$target scenario). I'll try to think of an approach that can cater to both use-cases.

@infinity0
Copy link
Contributor Author

I've used the existing approach with find_working_gnu_prefix - all builds green now

@alexcrichton
Copy link
Member

Thanks for this! This makes sense to me, but I'm hesitant to do so because it's such a commonly used target this seems likely to regress someone somewhere by accident. Could this implement some form of fallback where if these compilers aren't found it still stick with cc as the default?

@infinity0 infinity0 force-pushed the patch-2 branch 2 times, most recently from 62654fd to 0709230 Compare October 6, 2021 19:42
@infinity0
Copy link
Contributor Author

@alexcrichton that makes sense. I think this new version should do that? The only change since previously was to explicitly wrap the x86-64 case in self.find_working_gnu_prefix() as well. That way, if those compilers don't exist then the function will return None as it previously did. (This causes the caller to fall back to default "cc" as you want.)

Without the "// rustfmt wrap" workaround it wants to put the whole thing including comment on the same line which I thought was uglier, but happy to change this to whatever you prefer.

@alexcrichton
Copy link
Member

Seems reasonable to me! Can at least try it out and see what happens :)

@alexcrichton alexcrichton merged commit 3967ef3 into rust-lang:master Oct 6, 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.

None yet

2 participants