Spidermonkey fails to build because wrong rust target is chosen. Reproducible: Always Actual Results: Build fails, because it tries to use the wrong rust compiler. Expected Results: normal build. DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=armv7-gentoo-linux-musleabihf -o /home/portage/dev-lang/spidermonkey-78.7.0/temp/conftest5okne8yo.rlib /home/portage/dev-lang/spidermonkey-78.7.0/temp/conftestj5zl4boc.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 `armv7-gentoo-linux-musleabihf` target may not be installed DEBUG: | DEBUG: | error: aborting due to previous error This seems reasonable, cause I am not on glibc. In contrast: Called econf '--host=armv7a-raspberrypi-linux-gnueabihf' '--target=armv7a-raspberrypi-linux-gnueabihf' '--disable-jemalloc' '--disable-optimize' '--disable-strip' '--enable-readline' '--enable-shared-js' '--with-intl-api' '--with-system-icu' '--with-system-nspr' '--with-system-zlib' '--with-toolchain-prefix=armv7a-raspberrypi-linux-gnueabihf-' '--disable-debug' '--disable-jit' '--disable-tests' 'XARGS=/usr/bin/xargs' As can be seem econf uses -glibceabihf. However, using rust-bin I can build spidermonkey as expected. Logs will be added.
Created attachment 685887 [details] build.log build.log
Created attachment 685890 [details] emerge.info emerge --info
That should of course read -gnueabihf up there...
Looking into config.log, I can see: DEBUG: Executing: `/usr/bin/rustc --print target-list` INFO: checking for rust target triplet... DEBUG: Creating `/home/portage/dev-lang/spidermonkey-78.7.0/temp/conftest9lyavcv8.rs` with content: DEBUG: | pub extern fn hello() { println!("Hello world"); } DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=armv7-gentoo-linux-musleabihf -o /home/portage/dev-lang/spidermonkey-78.7.0/temp/conftestqdhmzqax.rlib /home/portage/dev-lang/spidermonkey-78.7.0/temp/conftest9lyavcv8.rs` Let's look at the output of the target list: # /usr/bin/rustc --print target-list|grep armv7 armv7-apple-ios armv7-gentoo-linux-musleabihf armv7-linux-androideabi armv7-unknown-cloudabi-eabihf armv7-unknown-freebsd armv7-unknown-linux-gnueabi armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabi armv7-unknown-linux-musleabihf armv7-unknown-netbsd-eabihf armv7-wrs-vxworks-eabihf armv7a-none-eabi armv7a-none-eabihf armv7r-none-eabi armv7r-none-eabihf armv7s-apple-ios Looks like the very first possible match is chosen. For rust-bin the output looks like this: # /usr/bin/rustc --print target-list|grep armv7 armv7-apple-ios armv7-linux-androideabi armv7-unknown-cloudabi-eabihf armv7-unknown-freebsd armv7-unknown-linux-gnueabi armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabi armv7-unknown-linux-musleabihf armv7-unknown-netbsd-eabihf armv7-wrs-vxworks-eabihf armv7a-none-eabi armv7a-none-eabihf armv7r-none-eabi armv7r-none-eabihf armv7s-apple-ios I don't know where the musleabif target in the target list of the local build originates from...
I did some testing.. I modified the target list (the bad way) and as soon as I am taking care of crippling the armv7-gentoo-linux-musleabihf a little, spidermonkey will instead choose armv7-unknown-linux-gnueabihf. Simply put, it looks a lot like spidemonkey's triplet choosing is broken.
I had a chance to take a peek at rust.configure. IT does some narrowing on the target, unfortunately it is not as readable as I hoped. I did not find otu yet, what's going wrong there. From what I can guess so far, the narrowing does not take the ABI into account at all, but maybe I am missing out on something.
I see that bug when trying to compile spidermonkey-78.6.0, too. One more interesting observation: I have successfully built a spidermonkey-78.6.0 binary package on January 22nd. And now I no longer can. So it looks to me as that bug had been covered until some package was updated between January 22nd and February 5th.
Am also experiencing this issue when attempting to build versions 78.6.0, 78.7.1, 78.8.0 and 78.9.0 of spidermonkey on a raspberry pi 4 (i.e. native compile). If required/requested, am happy to attach copy of build.log and output from 'emerge --info' for attempted build of 78.6.0 on my raspberry pi 4.
Same problem/error, on a Raspi 2 B+, when trying to compile 78.10.1.
*** Bug 805293 has been marked as a duplicate of this bug. ***
This is the same as bug 779178. Note that it affects *glibc* where misdetection occurs.
Same issue affects arm64 on musl, except that aarch64-gentoo-linux usage is attempted.
(In reply to Piotr Kubaj from comment #12) > Same issue affects arm64 on musl, except that aarch64-gentoo-linux usage is > attempted. I have installed the 64 bit version on a new SD card over the weekend. After a great deal of faffing about with upgrading Perl to latest, rebuilding kernel, and tool-chain, along with Rust, Spidermonkey built just fine on arm64. It's happily building Gnome right now.
