Closed Bug 1497778 Opened 6 years ago Closed 5 years ago

Cross-compiling spidermonkey for aarch64 fails with baldrapi compile error

Categories

(Core :: JavaScript: WebAssembly, defect, P3)

Product:
Core
Component:
JavaScript: WebAssembly
Platform:
ARM64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: lth, Assigned: bbouvier)

References

Details

Attachments

(3 files)

fix.patch
2.15 KB, patch
lth
: feedback-
Details | Diff | Splinter Review
full log.zip
25.46 KB, application/zip
Details
disable-cranelift.zip
25.84 KB, application/zip
Details
For bug 1394420 I am trying to cross-compile for aarch64 from my Linux x64 system, using Ubuntu's aarch64 gcc 7 toolchain and the current rustc for aarch64. Compiling cranelift-wasm I run into this error: error: failed to run custom build command for `baldrdash v0.1.0 (file:///home/lhansen/m-i/js/src/wasm/cranelift)` process didn't exit successfully: `/home/lhansen/m-i/js/src/build-arm64-cross/js/src/rust/debug/build/baldrdash-6ec889de9104bbfc/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-changed=baldrapi.h cargo:rerun-if-changed=/home/lhansen/m-i/js/src/build-arm64-cross/js/src/rust/extra-bindgen-flags --- stderr ../../wasm/WasmConstants.h:124:39: error: cast from pointer to smaller type 'intptr_t' (aka 'int') loses information ../../wasm/WasmConstants.h:124:39: error: cast from pointer to smaller type 'intptr_t' (aka 'int') loses information, err: true thread 'main' panicked at 'Unable to generate baldrapi.h bindings: ()', libcore/result.rs:945:5 Build configured as follows: export CC=aarch64-linux-gnu-gcc-7 export CXX=aarch64-linux-gnu-g++-7 ../configure --target=aarch64-unknown-linux-gnu --enable-debug --disable-optimize --without-intl-api
I guess it could look like bindgen is not picking up the correct inttypes.h? Probably via a misconfiguration in cranelift's build infrastructure, then.
Adding --verbose to the command line of clang executed by bindgen I also see this: clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: aarch64-unknown-linux-gnu Thread model: posix InstalledDir: Found candidate GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/7 Found candidate GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0 Selected GCC installation: /usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0 Candidate multilib: .;@m64 Selected multilib: .;@m64 ignoring nonexistent directory "/usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0/../../../../include/aarch64-linux-gnu/c++/7.3.0" ignoring nonexistent directory "/usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0/../../../../include/aarch64-unknown-linux-gnu/c++/7.3.0" ignoring nonexistent directory "lib/clang/6.0.0/include" ignoring nonexistent directory "/include" ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0" ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward" ignoring duplicate directory "/usr/include/clang/6.0.0/include" ignoring duplicate directory "/usr/local/include" ignoring duplicate directory "/usr/include" #include "..." search starts here: #include <...> search starts here: ../.. /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0 /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0 /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward /usr/include/clang/6.0.0/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include /usr/include/aarch64-linux-gnu End of search list.
(Compiling directly on the arm64 box also fails when building cranelift but apparently for other reasons, initially libclang missing but after that was installed it looks like some build artifact is not being run properly.) (/me reconfigures with --disable-cranelift...)
Ah right, the list of special options for aarch64 supposes that you're building for Android or Windows. Should be easy to fix by adding the target in the right case...
Attached patch fix.patch — — Splinter Review
Lars, does this fix your issue?
Assignee: nobody → bbouvier
Status: NEW → ASSIGNED
Attachment #9015797 - Flags: feedback?(lhansen)
Comment on attachment 9015797 [details] [diff] [review] fix.patch Review of attachment 9015797 [details] [diff] [review]: ----------------------------------------------------------------- I seriously doubt it will, because I tried that already, but I will try it just for grins...
Comment on attachment 9015797 [details] [diff] [review] fix.patch Review of attachment 9015797 [details] [diff] [review]: ----------------------------------------------------------------- Does not work, same error as before (about int vs intptr_t). (There's another bug here, in that a failed bindgen does not cause the build to stop, but that's small potatoes obviously.)
Attachment #9015797 - Flags: feedback?(lhansen) → feedback-
No idea what could be done here. Cc'ing Nathan since he's been working on arm64 and might have run into something like this before, maybe?
I haven't run into this, but I'm not sure I've tried compiling for aarch64 on windows since cranelift landed. That being said, this looks bogus: #include <...> search starts here: ../.. /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0 /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/c++/7.3.0 /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward /usr/include/clang/6.0.0/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include /usr/include/aarch64-linux-gnu What is compiling for aarch64 doing picking up include paths for x86-64? I was going to suggest --target, but I see that's been tried and it doesn't work. (We're sure that the appropriate --target is getting passed with the patch?) What does --verbose with the --target fix say? Is it possible to -save-temps or something on the bindgen'd file (emilio said this was possible, but I couldn't make it work) to see *where* that intptr_t definition is coming from?
Flags: needinfo?(lhansen)
Also, this seems not great: ignoring nonexistent directory "/usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0/../../../../include/aarch64-linux-gnu/c++/7.3.0" ignoring nonexistent directory "/usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0/../../../../include/aarch64-unknown-linux-gnu/c++/7.3.0" Are the appropriate C++ cross packages installed? Or is clang just looking in the wrong places?
(In reply to Nathan Froyd [:froydnj] from comment #9) > I haven't run into this, but I'm not sure I've tried compiling for aarch64 > on windows since cranelift landed. > > That being said, this looks bogus: > > #include <...> search starts here: > ../.. > /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0 > /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/x86_64-linux-gnu/ > c++/7.3.0 > /usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../../include/c++/7.3.0/backward > /usr/include/clang/6.0.0/include > /usr/local/include > /usr/include/x86_64-linux-gnu > /usr/include > /usr/include/aarch64-linux-gnu > > What is compiling for aarch64 doing picking up include paths for x86-64? > > I was going to suggest --target, but I see that's been tried and it doesn't > work. (We're sure that the appropriate --target is getting passed with the > patch?) What does --verbose with the --target fix say? > > Is it possible to -save-temps or something on the bindgen'd file (emilio > said this was possible, but I couldn't make it work) to see *where* that > intptr_t definition is coming from? You should be able to call builder.dump_preprocessed_input().unwrap() before generating the bindings: https://searchfox.org/mozilla-central/rev/80ac71c1c54af788b32e851192dfd2de2ec18e18/third_party/rust/bindgen/src/lib.rs#1181 If it doesn't work for any reason I'd be curious as of why. We maybe should be more lenient and let clang exit with non-zero status. Looks like even when it fails the preprocessed output should still be there.
Regarding the illegal paths, I think this is part of some sort of recurring Ubuntu misconfiguration. The following error messages go away when I create explicit links from /usr/include into the aarch64 hierarchy so that these paths work. I had to do the same for chrooted x86 builds, as per https://convolv.es/blog/2017/08/25/building-firefox-for-linux-32-bit/ (section "Building Firefox"). ignoring nonexistent directory "/usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0/../../../../include/aarch64-linux-gnu/c++/7.3.0" ignoring nonexistent directory "/usr/lib/gcc-cross/aarch64-linux-gnu/7.3.0/../../../../include/aarch64-unknown-linux-gnu/c++/7.3.0" Making the headers available does not make the compilation problem go away however. I think what you're looking at above is the --verbose output /with/ the --target fix, but without manually linking the header files. Otherwise it wouldn't be looking for the aarch64 headers, I think.
Flags: needinfo?(lhansen)

Hit this yesteray, when going for a cross-compile of firefox based on nightly mozilla-central. Did you found out more since this has been reported six months ago?

(In reply to tt_1 from comment #13)

Hit this yesteray, when going for a cross-compile of firefox based on nightly mozilla-central. Did you found out more since this has been reported six months ago?

No, but we are at least able to cross-compile successfully on a debian9-based system in mozilla automation; I don't know whether lth has been more or less successful since then. That suggests that the problem is with Ubuntu in some way. If you're willing to dig in and provide more details along the lines of comment 2 and comment 11, that would be helpful.

I'm not on ubuntu and not on any debianish distro either, so could you point out to the debian9-based stuff for me to learn from it?

I don't know whether lth has been more or less successful since then

lth made no further attempts.

I dug a bit further into this:

download gecko-dev-master.zip from github, it saved me a lof of traffic compared to a hg checkout, then:

cd gecko-dev-master/js/src/
autoconf-2.13
mkdir build_OPT.OBJ && cd build_OPT.OBJ

../configure --target=aarch64-unknown-linux-gnu --disable-jemalloc --enable-readline --with-system-nspr --with-system-zlib --disable-optimize --with-intl-api --with-system-icu --disable-debug --enable-ion --disable-tests

make -j12

and fails with this error:

--- stderr
/usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
/usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found, err: true
thread 'main' panicked at 'Unable to generate baldrapi.h bindings: ()', src/libcore/result.rs:1009:5

I'll attach the build.log as soon as I find out where

Is this
a) part of cranelift, and hence --disable-cranelift may be helping?
b) a indication that rust has to be build with wasm target? wasm seems to be 32bit, so might be the source of the wrong include? (wasm32-unknown-unknown)

Attached file full log.zip —

full build.log

Attached file disable-cranelift.zip —

--disable-cranelift makes the standalone compile work

file libmozjs-68a1.so
libmozjs-68a1.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2c5b4115e3ef39eb62b5d7f2db4a7e5623d941e6, with debug_info, not stripped

file js
js: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=76063aeac6f98edfb4cd78c443de8e7c7f2ccc83, with debug_info, not stripped

and stripped:

libmozjs-68a1.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2c5b4115e3ef39eb62b5d7f2db4a7e5623d941e6, stripped

js: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=76063aeac6f98edfb4cd78c443de8e7c7f2ccc83, stripped

seems legit?

So, after having a bit of a chat with the cranelift-devs it turns out that there is only runtime support for amd64 at the moment. That means it might be possible to compile it on other arches, but there isn't yet any port ready, other than amd64.

For firefox/spidermonkey this means passing --disable-cranelift by default unless the build is meant for amd64, should be sufficent as a temporarilly workaround.

Oh, and there's another bug in the cc crate, which misdetects gcc if it's a crosscompile and the individual symlink to the gcc cross-compiler isn't to be found in /usr/bin/, with debianish name-patterns. /usr/bin/arm-linux-gnueabihf-gcc is what it seeks, at least fedora and gentoo have different CHOST. Setting a symlink is sufficent as a workaround.

Priority: P2 → P3

Lars, is this still an issue, or can we close it?

Flags: needinfo?(lhansen)

Let's not worry about it; it works in automation, and I'm no longer on Ubuntu, plus I have an ARM64 dev system :-)

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(lhansen)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: