LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 07-31-2020, 11:47 AM   #1
resolver
Member
 
Registered: Jun 2020
Posts: 49

Rep: Reputation: Disabled
Rust architecture bug


While I was trying to compile Firefox, because the provided one is outdated, I discovered that Rust is not properly configured in Slackware ARM.

You can try it yourself but basically rustc believes the architecture is
Code:
armv7-unknown-linux-gnueabihf
in one place but
Code:
arm-unknown-linux-gnueabihf
in another spot, which causes it to demand that a new Rust std library be downloaded in binary form using the missing rustup utility. They don't even allow building it from source.

Can someone in the Slackware ARM project please fix this? I do not want to download binaries from the Rust community, and it's better to fix the original cause of the error rather than correct for it separately on each computer.

By the way, which is the platform "unknown"? Shouldn't it be set to slackwarearm somewhere in /etc?

Last edited by resolver; 07-31-2020 at 11:49 AM.
 
Old 08-01-2020, 04:13 AM   #2
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by resolver View Post
While I was trying to compile Firefox, because the provided one is outdated, I discovered that Rust is not properly configured in Slackware ARM.
The reason Firefox isn't updated yet is because it hangs whilst linking. I'm going to hack away at it from time to time, but it may have finally run its course if I can't build with 2GB RAM.

Quote:

You can try it yourself but basically rustc believes the architecture is
Code:
armv7-unknown-linux-gnueabihf
in one place but
Code:
arm-unknown-linux-gnueabihf
in another spot, which causes it to demand that a new Rust std library be downloaded in binary form using the missing rustup utility. They don't even allow building it from source.
Where is this difference? It's built as armv7-unknown-linux-gnueabihf.

Quote:
Can someone in the Slackware ARM project please fix this? I do not want to download binaries from the Rust community, and it's better to fix the original cause of the error rather than correct for it separately on each computer.

By the way, which is the platform "unknown"? Shouldn't it be set to slackwarearm somewhere in /etc?

I had all sorts of problems with rust, so I am using the 'unknown' value explicitly within the SlackBuild because there are settings for it within the rust source. Originally it was named armv7-slackware-linux-gnueabihf, but that broke stuff.
I've not found any problems doing this for a couple of years, and I found that at least Fedora ARM was using the same value so I stopped efforts to make it 'proper' at that point.
I'll set the latest Firefox building again to see if there's an issue with it and take it from there.
 
1 members found this post helpful.
Old 08-01-2020, 08:57 AM   #3
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
After a fresh installation, this is what happens building Firefox

Code:
*** WARNING: distcc is now disabled
 0:06.75 Clobber not needed.
 0:06.75 Adding make options from /root/tmp/build-mozilla-firefox/firefox-78.1.0/.mozconfig
    MOZ_OBJDIR=/root/tmp/build-mozilla-firefox/firefox-78.1.0/obj
    OBJDIR=/root/tmp/build-mozilla-firefox/firefox-78.1.0/obj
    FOUND_MOZCONFIG=/root/tmp/build-mozilla-firefox/firefox-78.1.0/.mozconfig
    export FOUND_MOZCONFIG
 0:06.79 /usr/bin/gmake -f client.mk -s
 0:08.52 Elapsed: 0.01s; From dist/public: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:08.57 Elapsed: 0.01s; From dist/private: Kept 0 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:10.08 Elapsed: 0.01s; From dist/xpi-stage: Kept 5 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:11.34 Elapsed: 1.20s; From _tests: Kept 556 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:13.71 Elapsed: 5.19s; From dist/include: Kept 5695 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:14.31 Elapsed: 2.73s; From dist/bin: Kept 2655 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:14.52 ./buildid.h.stub
 0:15.96 ./source-repo.h.stub
 0:18.09 build/application.ini.stub
 0:18.15 layout/style/ServoStyleConsts.h.stub
 0:19.02 dom/media/audioipc_client_ffi_generated.h.stub
 0:19.88 build/application.ini.h.stub
 0:21.92 gfx/webrender_bindings/webrender_ffi_generated.h.stub
 0:35.25 b''
 0:35.26 b'ERROR: Couldn\'t execute `cargo metadata` with manifest "/root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust/Cargo.toml": Metadata(Output { status: ExitStatus(ExitStatus(4)), stdout: "", stderr: "" })\nERROR: Couldn\'t generate bindings for /root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust.\n'
 0:35.37 gmake[4]: *** [backend.mk:82: .deps/ServoStyleConsts.h.stub] Error 1
 0:35.37 gmake[3]: *** [/root/tmp/build-mozilla-firefox/firefox-78.1.0/config/recurse.mk:101: layout/style/export] Error 2
 0:35.37 gmake[3]: *** Waiting for unfinished jobs....
 0:48.33 b''
 0:48.34 b'ERROR: Couldn\'t execute `cargo metadata` with manifest "/root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust/Cargo.toml": Metadata(Output { status: ExitStatus(ExitStatus(4)), stdout: "", stderr: "    Blocking waiting for file lock on package cache\\n" })\nERROR: Couldn\'t generate bindings for /root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust.\n'
 0:48.45 gmake[4]: *** [backend.mk:13: .deps/audioipc_client_ffi_generated.h.stub] Error 1
 0:48.45 gmake[3]: *** [/root/tmp/build-mozilla-firefox/firefox-78.1.0/config/recurse.mk:101: dom/media/export] Error 2
 1:01.46 b''
 1:01.46 b'ERROR: Couldn\'t execute `cargo metadata` with manifest "/root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust/Cargo.toml": Metadata(Output { status: ExitStatus(ExitStatus(4)), stdout: "", stderr: "    Blocking waiting for file lock on package cache\\n" })\nERROR: Couldn\'t generate bindings for /root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust.\n'
 1:01.57 gmake[4]: *** [backend.mk:12: .deps/webrender_ffi_generated.h.stub] Error 1
 1:01.57 gmake[3]: *** [/root/tmp/build-mozilla-firefox/firefox-78.1.0/config/recurse.mk:101: gfx/webrender_bindings/export] Error 2
 1:01.57 gmake[2]: *** [/root/tmp/build-mozilla-firefox/firefox-78.1.0/config/recurse.mk:34: export] Error 2
 1:01.57 gmake[1]: *** [/root/tmp/build-mozilla-firefox/firefox-78.1.0/config/rules.mk:390: default] Error 2
 1:01.58 gmake: *** [client.mk:125: build] Error 2
 1:01.60 0 compiler warnings present.
removed '/tmp/DISTCC/arm-slackware-linux-gnueabihf-gcc'
removed '/tmp/DISTCC/cc'
Is that what you see? There's not much immediately useful that I can find to address that, so I'd need to dig into that some more.
I don't see anything specific to the rust package there though. This issue appeared only with the newer version of Firefox so it's probably something localised to that. I'll try rebuilding the older version of Firefox first and see what happens.
 
Old 08-01-2020, 11:38 AM   #4
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by drmozes View Post
0:35.26 b'ERROR: Couldn\'t execute `cargo metadata` with manifest "/root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust/Cargo.toml": Metadata(Output { status: ExitStatus(ExitStatus(4)), stdout: "", stderr: "" })\nERROR: Couldn\'t generate bindings for /root/tmp/build-mozilla-firefox/firefox-78.1.0/toolkit/library/rust.\n'

[/code]
This is just some bug in the build script. I've fixed this so it ought to get past it now.
 
Old 08-01-2020, 05:59 PM   #5
resolver
Member
 
Registered: Jun 2020
Posts: 49

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
The reason Firefox isn't updated yet is because it hangs whilst linking. I'm going to hack away at it from time to time, but it may have finally run its course if I can't build with 2GB RAM.
Can you make your scripts and config files accessible? I have 8GB so maybe I can build it. I looked at the build scripts in the x86 FF source directory and couldn't figure out how to get them to work.

Quote:
Originally Posted by drmozes View Post
Where is this difference? It's built as armv7-unknown-linux-gnueabihf.
FF's build system complains that it can't find rustc std library. So arm vs armv7 confuses it. I tried renaming the library directory to match what it wanted but that didn't help it. I wish Mozilla weren't using rust.

Quote:
Originally Posted by drmozes View Post
I'll set the latest Firefox building again to see if there's an issue with it and take it from there.
OK, thanks.

Last edited by resolver; 08-01-2020 at 06:07 PM.
 
Old 08-03-2020, 12:03 AM   #6
resolver
Member
 
Registered: Jun 2020
Posts: 49

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
Is that what you see?
I'm trying to build FF 79.0.

Code:
checking for rustc... /usr/bin/rustc
checking for cargo... /usr/bin/cargo
checking rustc version... 1.45.0
checking cargo version... 1.45.0
checking for rust target triplet... 
DEBUG: Creating `/tmp/conftests8j94ww9.rs` with content:
DEBUG: | pub extern fn hello() { println!("Hello world"); }
DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=arm-unknown-linux-gnueabihf -o /tmp/conftestx57s9ids.rlib /tmp/conftests8j94ww9.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 `arm-unknown-linux-gnueabihf` 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 armv7l-unknown-linux-gnueabihf with /usr/bin/rustc
The target may be unsupported, or you may not have
a rust std library for that target installed. Try:

  rustup target add arm-unknown-linux-gnueabihf
 
Old 08-03-2020, 02:40 AM   #7
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by resolver View Post
I'm trying to build FF 79.0.
I haven't seen that before, but I'm also not building v79 - Slackware-current has v78. I had the same problem with cargo that I pasted in in a previous reply when building the v68 ESR release of Firefox. I downgraded to rustc 1.43.1 and have built the latest v68 ESR release. There's a newer version of rust available now so I'll see how that fares next.

Your issue might be using the x86_64 source tree. You'd be better to use the ARM source tree, but it needs a little prep work before you can use it. However, there's a README in the root of the source directory which explains it clearly.
 
Old 08-03-2020, 11:12 AM   #8
resolver
Member
 
Registered: Jun 2020
Posts: 49

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
Your issue might be using the x86_64 source tree.
What I pasted above was the result of using the source code from Mozilla. I tried downloading 78.1 and I get a nearly identical result running configure.

I don't have a previous rustc to fall back on so I'm going to try to build and install the latest one before trying FF again.

By the way, do you know how to compile rust in such a way that it doesn't download any binary packages? It has this pernicious tendency for some reason.

UPDATE: Rust is recompiling a ton of basic programs including things like tar, cc, xz, xattr and so on. The build directory is nearly 7 GB. The fact that it wanted to download binaries was the first red flag. The fact that it won't use preexisting installed programs is a second red flag. Rust is garbage software. I like Firefox but if building it requires rust I may have to give it up.

I find myself wondering whether the tar, xattr etc that are on my system are the ones you selected and built, or whether they're the replacements that rust compiled. Did you notice anything strange when you built rust?

Have you considered maybe adding ungoogled-chromium to Slackware ARM? I successfully built that once in the past. It wasn't such a big ordeal.

Last edited by resolver; 08-04-2020 at 01:46 PM.
 
Old 08-06-2020, 08:08 AM   #9
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by resolver View Post
By the way, do you know how to compile rust in such a way that it doesn't download any binary packages?
I don't think that it does when using the Slackware rust build script, although I might be wrong. Keeping track of what it does isn't top priority - it's just good when it builds and works!

Quote:
UPDATE: Rust is recompiling a ton of basic programs including things like tar, cc, xz, xattr and so on. The build directory is nearly 7 GB. The fact that it wanted to download binaries was the first red flag. The fact that it won't use preexisting installed programs is a second red flag. Rust is garbage software. I like Firefox but if building it requires rust I may have to give it up.

I find myself wondering whether the tar, xattr etc that are on my system are the ones you selected and built, or whether they're the replacements that rust compiled. Did you notice anything strange when you built rust?
If you look at the source, it explains what they are. They're libraries for rust and seem to be either rust-native implementations of system features (such as management of extended file attributes 'xattr'), or bindings to the normal C library functions (as is the case for 'curl').

Quote:
Have you considered maybe adding ungoogled-chromium to Slackware ARM? I successfully built that once in the past. It wasn't such a big ordeal.
Not whilst Firefox works.

I think that the 1.45.0 release of rust is duff. I've built the latest version and it now works with the limited test cases I've used, so I'll see what happens with the latest Firefox again.
 
Old 08-07-2020, 08:56 AM   #10
resolver
Member
 
Registered: Jun 2020
Posts: 49

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
Keeping track of what it does isn't top priority - it's just good when it builds and works!
Think for a moment. That is the exact same thinking that has led to multitudes of people's computers getting Trojans installed on them.

It's a classic mistake. For instance: A person sees a webpage saying "Update your flash player to view this lurid page!" so they do, and bingo, they're infected.

Taking an obvious risk because you think the payoff justifies it is one thing is if it just your computer that could get infected.

But as a distro maintainer you have a responsibility to not put users at risk. That means not cutting corners with computer security.
If rust is downloading binaries, and it clearly is, that's unacceptable and some other safer means has to be found.
 
Old 08-07-2020, 10:44 AM   #11
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,613

Rep: Reputation: 893Reputation: 893Reputation: 893Reputation: 893Reputation: 893Reputation: 893Reputation: 893
Quote:
Originally Posted by resolver View Post
I'm trying to build FF 79.0.
Code:
ERROR: Cannot compile for armv7l-unknown-linux-gnueabihf with /usr/bin/rustc
The target may be unsupported, or you may not have
a rust std library for that target installed. Try:

  rustup target add arm-unknown-linux-gnueabihf
armv7l-unknown-linux-gnueabihf looks to be the resulted target composition from a config.guess script called somewhere in the build system, which uses several uname commands. uname -m will output armv7l, the same as in /proc/cpuinfo and it's coming from the kernel.
The mismatch between armv7l-unknown-linux-gnueabihf and arm-unknown-linux-gnueabihf (apparently the only available predefined target) could be fixed by modifying the build scripts and I'd suggest to let the rust devs fix it - just highlight it for them.
unknown on the other hand, as already noticed, shouldn't have any negative impact.
https://unix.stackexchange.com/quest...-in-arch-linux

Last edited by abga; 08-07-2020 at 10:52 AM. Reason: typo
 
Old 08-07-2020, 11:06 AM   #12
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by resolver View Post
Think for a moment. That is the exact same thinking that has led to multitudes of people's computers getting Trojans installed on them.

It's a classic mistake. For instance: A person sees a webpage saying "Update your flash player to view this lurid page!" so they do, and bingo, they're infected.

Taking an obvious risk because you think the payoff justifies it is one thing is if it just your computer that could get infected.

But as a distro maintainer you have a responsibility to not put users at risk. That means not cutting corners with computer security.
If rust is downloading binaries, and it clearly is, that's unacceptable and some other safer means has to be found.
All good and valid points with which I am in 100% agreement. The nub of the problem is that even to build rust originally, you need a rust compiler, which means you need to rely on binaries at the bootstrap stage. At this point you rely on the validation in TLS and secure signatures of binaries.
You should take this up with the rust developers.

Last edited by drmozes; 08-07-2020 at 11:07 AM.
 
Old 08-08-2020, 11:05 PM   #13
resolver
Member
 
Registered: Jun 2020
Posts: 49

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
At this point you rely on the validation in TLS and secure signatures of binaries.
That's assuming their servers are not hacked, or a hacker hasn't surreptitiously joined their project in order to implant malware.

Quote:
Originally Posted by drmozes View Post
You should take this up with the rust developers.
I'll email them.
 
Old 08-09-2020, 08:04 AM   #14
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 946

Rep: Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753Reputation: 753
Quote:
Originally Posted by resolver View Post
That's assuming their servers are not hacked, or a hacker hasn't surreptitiously joined their project in order to implant malware.
Unless you inspect and understand what the code base of a project is doing, I cannot see a real difference between using a binary and source code. As a layer of security, Debian have (or had - I don't know if it's still the practice) a 'key signing' party where people physically turn up and exchange their GPG keys on a USB stick (IIRC!) so they get to meet the developers IRL, and the established developers approve the addition of new developers.

Even when the source is signed, you're relying on the signature and all of the infrastructure that supports it.
Binaries aren't different in that respect, at least to me! But certainly you'd typically not want to do this as part of a build process, for other reasons such as consistency.


Anyway, we have established (referring to your thread in the main Slackware forum), Slackware does not download binaries nor source during the rust build. It doesn't on ARM either.
If you are referring to 'rustup' - this isn't how Slackware packages rust, so the issue we're discussing is a moot point in regards to Slackware.

The issue with the mismatch of tool chain/arch name is odd though. You're using clang to compile Firefox, I suspect. I was using gcc and just switched to clang and run into the same problem.
rust works fine with gcc though, but FF still hangs at the linking stage.
I'm not sure what's up with rust - the build settings look good. I am going to hack on it a bit and see what happens.

Last edited by drmozes; 08-09-2020 at 08:10 AM.
 
1 members found this post helpful.
Old 08-10-2020, 12:20 AM   #15
resolver
Member
 
Registered: Jun 2020
Posts: 49

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by drmozes View Post
Anyway, we have established (referring to your thread in the main Slackware forum), Slackware does not download binaries nor source during the rust build. It doesn't on ARM either.
I haven't looked at that thread, but Rust project has confirmed that the compiler is written in rust, therefore you need the rust binary to compile rust. So it's coming from somewhere and if that compiler is infected with clever malware it could propagate itself across compiler versions.

Quote:
I cannot see a real difference between using a binary and source code.
If you blindly trust binaries, there is nothing to stop a malevolent person (and NSA or GCHQ operative perhaps) from inserting malware into binaries and falsely claiming they come from the public source code. All they have to do is patch the public version, compile and claim the binary's benevolent.

Haven't you heard of reproducible builds?

Last edited by resolver; 08-10-2020 at 12:22 AM.
 
  


Reply

Tags
firefox, rustc, slackware -current, slackware arm


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Cisco Confirms 88 Products Vulnerable to FragmentStack Bug, KDE neon Rebased on Ubuntu 18.04 LTS, GNOME 3.30.1 Released, Rust Announce LXer Syndicated Linux News 0 09-27-2018 05:30 AM
LXer: This week at LWN: A taste of Rust LXer Syndicated Linux News 0 04-26-2013 08:42 PM
LXer: Mozilla's Rust language version 0.3 released LXer Syndicated Linux News 0 07-13-2012 03:50 PM
how can i port a driver with a specific architecture into another architecture? the hope Linux - Hardware 4 03-23-2011 05:39 PM
what is 'architecture' in 'binary for an architecture'?multiple architecture support? wagaboy Linux - Newbie 2 07-10-2010 11:18 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 10:20 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration