Closed Bug 1658976 Opened 4 months ago Closed 3 months ago

Unable to compile 32-bit SpiderMonkey builds on 64-bit Linux

Categories

(Firefox Build System :: General, defect, P3)

defect

Tracking

(firefox-esr68 unaffected, firefox-esr78 unaffected, firefox79 unaffected, firefox80 unaffected, firefox81 wontfix, firefox82 fixed)

RESOLVED FIXED
82 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox79 --- unaffected
firefox80 --- unaffected
firefox81 --- wontfix
firefox82 --- fixed

People

(Reporter: gkw, Assigned: mhentges)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files)

After bug 1658053 landed, I am now unable to compile 32-bit SpiderMonkey builds on 64-bit Linux.

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/839ec6bf112e
user:        Nathan Froyd
date:        Thu Aug 13 11:36:08 2020 +0000
summary:     Bug 1658053 - update config.{guess,sub} with arm64 macOS support; r=glandium
Flags: needinfo?(nfroyd)

Initially the error was:

checking rustc version... 1.45.2
checking cargo version... 1.45.1
checking for rust target triplet... i686-unknown-linux-gnu
checking for rust host triplet... 
DEBUG: Creating `/tmp/conftestjipyw8e2.rs` with content:
DEBUG: | pub extern fn hello() { println!("Hello world"); }
DEBUG: Executing: `/home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --crate-type staticlib --target=x86_64-unknown-linux-gnux32 -o /tmp/conftest3uwmzwxb.rlib /tmp/conftestjipyw8e2.rs`
DEBUG: The command returned non-zero exit status 1.
DEBUG: Its error output was:
DEBUG: | error[E0463]: can't find crate for `std`
DEBUG: |   |
DEBUG: |   = note: the `x86_64-unknown-linux-gnux32` target may not be installed
DEBUG: | 
DEBUG: | error: aborting due to previous error
DEBUG: | 
DEBUG: | For more information about this error, try `rustc --explain E0463`.
ERROR: Cannot compile for x86_64-pc-linux-gnux32 with /home/runner/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc
The target may be unsupported, or you may not have
a rust std library for that target installed. Try:

  rustup target add x86_64-unknown-linux-gnux32

After I followed the suggestion to run rustup target add x86_64-unknown-linux-gnux32, I get:

checking rustc version... 1.45.2
checking cargo version... 1.45.1
checking for rust target triplet... i686-unknown-linux-gnu
checking for rust host triplet... x86_64-unknown-linux-gnux32
ERROR: The rust compiler host (x86_64-unknown-linux-gnu) is not suitable for the configure host (x86_64-pc-linux-gnux32/x86_64-unknown-linux-gnux32).

What should be the right way forward?

Gonna need a mozconfig to have any inkling of what's going on here. Your rust error looks like somebody thinks you're trying to compile for the x32 64-bit ABI, so you might need to be more specific in your --target.

Flags: needinfo?(nfroyd)

Please paste or attach the complete configure output.

An example configure command used is:

PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig 'CXX="clang++ -m32 -msse2 -mfpmath=sse"' 'CC="clang -m32 -msse2 -mfpmath=sse"' AR=ar sh <path to>/mozilla-central/js/src/configure --target=i686-pc-linux --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

I'll try and get more details.

That said, :tcampbell suggested using i686-pc-linux instead. Is that a better alternative?

Why do the command line and tcampbell's suggestion match? Aren't they supposed to be different?

oh hmmm, I think the reason may be that I had installed i686-unknown-linux-gnu via rustup during setup. This combination with the configure command had worked till recently.

Perhaps I should fix up my rustup stuff by uninstalling both i686-unknown-linux-gnu and x86_64-unknown-linux-gnux32 targets, and only installing the i686-pc-linux target?

(in which case this wouldn't really be a SpiderMonkey/Firefox build system issue) - let me check if this works.

Nope, it does not work:

$ rustup target add i686-pc-linux
error: toolchain 'stable-x86_64-unknown-linux-gnu' does not contain component 'rust-std' for target 'i686-pc-linux'
$ rustup target list | grep x86_64
x86_64-apple-darwin
x86_64-apple-ios
x86_64-fortanix-unknown-sgx
x86_64-fuchsia
x86_64-linux-android
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-rumprun-netbsd
x86_64-sun-solaris
x86_64-unknown-cloudabi
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu (installed)
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl
x86_64-unknown-netbsd
x86_64-unknown-redox
$ rustup target list | grep i686
i686-linux-android
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-freebsd
i686-unknown-linux-gnu
i686-unknown-linux-musl

Now I'm confused. Which targets from https://github.com/rust-lang/rustup#other-installation-methods should I install on my 64-bit Linux via rustup to be able to compile 32-bit builds?

Corresponding configure command for comment #9 is AR=ar PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig 'CC="clang -m32 -msse2 -mfpmath=sse"' 'CXX="clang++ -m32 -msse2 -mfpmath=sse"' sh /home/skygentoo/trees/mozilla-central/js/src/configure --target=i686-pc-linux --enable-debug --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests --with-libclang-path=/usr/lib/llvm/9/lib64

Same configure command: AR=ar 'CXX="clang++ -m32 -msse2 -mfpmath=sse"' PKG_CONFIG_PATH=/usr/lib/x86_64-linux-gnu/pkgconfig 'CC="clang -m32 -msse2 -mfpmath=sse"' sh /home/skygentoo/trees/mozilla-central/js/src/configure --target=i686-pc-linux --enable-debug --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests --with-libclang-path=/usr/lib/llvm/9/lib64

$ rustup target list | grep nstalled
i686-unknown-linux-gnu (installed)
x86_64-unknown-linux-gnu (installed)
x86_64-unknown-linux-gnux32 (installed)

So here's where the problem starts:
checking for host system type... x86_64-pc-linux-gnux32

config.guess is saying your host is 32-bits x86_64. Which sounds like it could be true.
And since your rust compiler is a 64-bits x86_64 one, that doesn't match.

Try --host=x86_64-pc-linux-gnu.

And the reason config.guess returns a x32 triple is that your cc compiler must be compiling for that target by default.

(In reply to Mike Hommey [:glandium] from comment #12)

Try --host=x86_64-pc-linux-gnu.

Bingo! This solved the issue.

Perhaps this can be resolved, not a Mozilla bug or something?

I think there's something we can (and should) do about it:

  • avoid error[E0463]: can't find crate for std being the first error you get. We should complain about the mismatch between the host rust target and configure host target before that, which would make things a little better from a user perspective.
  • add a suggested fix for the configure mismatch situation, which in this case would have been saying to try either use --host=x86_64-pc-linux-gnu, or installing a x86_64-pc-linux-gnux32 rust compiler (the compiler itself, not a rust compiler that can target that, which you end up with if you follow the current advice to install the target from the first error).

What does clang -m32 -msse2 -mfpmath=sse -E -dM -x c /dev/null -o - say? I find it kind of hard to believe that you're running a native x32 setup, or that -m32 would activate x32.

Flags: needinfo?(nth10sd)

I was told to use -m32 since years ago, and it has always worked to get a 32-bit build while being on a 64-bit Linux host. Worked on both Ubuntu and Gentoo.

Let me know if I shouldn't use this.

Flags: needinfo?(nth10sd) → needinfo?(nfroyd)

You can remove -m32, the build system will add it on its own.

Assignee: nobody → mhentges
Severity: -- → S3
Priority: -- → P3

I'll add something else to comment 15: we should probably unset CC_FOR_BUILD, HOST_CC, and CC from the environment when calling config.guess.

-m32 should be fine, afaik.

Flags: needinfo?(nfroyd)

Previously, we would optimistically attempt to use a Rust toolchain that
matches the current C toolchain, and would throw an error if an
attempted compile with that Rust toolchain failed.

Instead, if we fail to detect a usable Rust toolchain, we now helpfully
inform users of their two options: change C toolchain, or install
matching Rust toolchain.

config.guess infers information about the compiler using environment
variables, such as CC. However, we use such environment variables to
configure the tooling for the target.

Depends on D88084

Pushed by mhentges@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bcfab5a318fb
If usable Rust toolchain can't be found, print useful error r=froydnj
https://hg.mozilla.org/integration/autoland/rev/80fa7f7eea54
Configure more-accurately detects host triplet r=froydnj

Whoops, missed a step - 80fa7f7eea54 is missing a change that was erroneously not submitted to Phabricator.
Standing by for backout, then I'll re-land this

Thanks! Fix is pushed, landing again

Flags: needinfo?(mhentges)
Pushed by mhentges@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/fcc9554c76fe
If usable Rust toolchain can't be found, print useful error r=froydnj
https://hg.mozilla.org/integration/autoland/rev/80beec7aca1f
Configure more-accurately detects host triplet r=froydnj
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
You need to log in before you can comment on or make changes to this bug.