Firefox failing builds.

mistersmee · 2021-01-17 17:41:25

Hey @deep42thought and/or @andreas_baumann, I checked up on firefox, and the build logs in https://www.archlinux32.org/buildmaster … &q=firefox, and it is failing because a patch has changed.
So, I tried to resolve it, and here is the working patch.

rust-static-disable-network-test-on-static-libraries.patch

diff -rauN a/config/makefiles/rust.mk b/config/makefiles/rust.mk
--- a/config/makefiles/rust.mk	2020-10-13 20:23:09.920635480 +0200
+++ b/config/makefiles/rust.mk	2020-10-13 20:24:02.273994137 +0200
@@ -324,17 +324,17 @@
 # the chance of proxy bypasses originating from rust code.
 # The check only works when rust code is built with -Clto but without MOZ_LTO_RUST_CROSS.
 # Sanitizers and sancov also fail because compiler-rt hooks network functions.
-ifndef MOZ_PROFILE_GENERATE
-ifeq ($(OS_ARCH), Linux)
-ifeq (,$(rustflags_sancov)$(MOZ_ASAN)$(MOZ_TSAN)$(MOZ_UBSAN))
-ifndef MOZ_LTO_RUST_CROSS
-ifneq (,$(filter -Clto,$(cargo_rustc_flags)))
-	$(call py_action,check_binary,--target --networking $@)
-endif
-endif
-endif
-endif
-endif
+#ifndef MOZ_PROFILE_GENERATE
+#ifeq ($(OS_ARCH), Linux)
+#ifeq (,$(rustflags_sancov)$(MOZ_ASAN)$(MOZ_TSAN)$(MOZ_UBSAN))
+#ifndef MOZ_LTO_RUST
+#ifneq (,$(filter -Clto,$(cargo_rustc_flags)))
+#	$(call py_action,check_binary,--target --networking $@)
+#endif
+#endif
+#endif
+#endif
+#endif
 
 force-cargo-library-check:
 	$(call CARGO_CHECK) --lib $(cargo_target_flag) $(rust_features_flag)

It starts building, however I do not know anything after that, as my potato laptop cannot do this monumental task. 100% 1gb memory+ 100% swap on a weak Core Duo 32-bit processor != firefox building and a good time.
I imagine that it should build after that.
I cannot commit this change directly to the git repo containing the patch, so communicating through here.

Last edited by mistersmee (2021-01-17 17:45:09)

deep42thought · 2021-01-18 08:11:54

thanks, I committed the patch - let's see, what the build slaves have to say about it :-)

mistersmee · 2021-01-19 07:42:37

Cool!
Do the build slaves update the checksums automatically? Because the build will fail with a verifying error now, because the checksums for the patch is unchanged, while the patch itself has changed.

Last edited by mistersmee (2021-01-19 07:43:21)

deep42thought · 2021-01-19 07:48:31

mistersmee wrote:

Do the build slaves update the checksums automatically? Because the build will fail with a verifying error now, because the checksums for the patch is unchanged, while the patch itself has changed.

They don't. It's an oversight from my part.

mistersmee · 2021-01-19 09:17:43

Great, aand now it's failing because rust 1-47 is looking for llvm-10 while the version of llvm available is 11. And the versions of rust which look for the correct llvm versions tried to build a few weeks ago but do this :-
rustup 1-23 builds failed because of the 403 errors of the mirrors that occurred a while ago described here, and rust 1-49 builds failed because of something similar to this.
And have not tried to build recently since.

I had tried to build before the llvm update pushed through, and so it did not complain then for me.
And today, I had gotten access to a 64-bit machine running Manjaro, but obviously, despite it being Arch-based, it is dissimilar enough that although it technically can build using the multilib repo and our makepkg.conf, it errors out due to the differences between the distros.

And hopefully that is the end of the reasons to not build. Hopefully, there are no rust problems like the recent bug that resulted in firefox not compiling for rust 1-48 everywhere, and it finally builds.

Such a melodramatic program to build, this firefox.

Last edited by mistersmee (2021-01-19 09:47:45)

deep42thought · 2021-01-19 15:04:47

rust is apparently waiting for cmake, which failed to build due to some broken libicu linking. I'll try to fix it from the end of this sentence to the beginning.

abaumann · 2021-01-20 18:33:11

You can temporarily add makedepends=('llvm10'), so that Rust still works, but usually a specific version of firefox requires a very
specific version of rust to build. Usually you have to bootstrap rust (from former versions or from rust-bin (see AUR)).

deep42thought · 2021-01-21 16:39:36

abaumann wrote:

You can temporarily add makedepends=('llvm10'), so that Rust still works, ...

:: llvm and llvm10 are in conflict. Remove llvm10? [y/N] 
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: llvm and llvm10 are in conflict
==> ERROR: 'pacman' failed to install missing dependencies.

nope, won't work - llvm and llvm10 cannot be installed along each other.

mistersmee · 2021-01-22 13:54:21

deep42thought wrote:

abaumann wrote:
You can temporarily add makedepends=('llvm10'), so that Rust still works, ...
:: llvm and llvm10 are in conflict. Remove llvm10? [y/N] 
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: llvm and llvm10 are in conflict
==> ERROR: 'pacman' failed to install missing dependencies.
nope, won't work - llvm and llvm10 cannot be installed along each other.

Maybe llvm10-libs will work?
It specifically provides libLLVM-10.so which is what rust and other programs are complaining about being missing.
And it doesn't conflict with llvm.
Btw, installing llvm10-libs fixed a host of little problems that I didn't even notice had come up on my system when llvm got upgraded to 11. mpv was able to use vdpau as output backend, which I hadn't realised was missing.
Maybe all the programs that depend upon llvm haven't caught on that llvm was upgraded to version 11?
Just like some python stuff is still stuck on python3.8.

Last edited by mistersmee (2021-01-22 14:00:09)

mistersmee · 2021-01-22 14:05:37

abaumann wrote:

You can temporarily add makedepends=('llvm10'), so that Rust still works, but usually a specific version of firefox requires a very
specific version of rust to build. Usually you have to bootstrap rust (from former versions or from rust-bin (see AUR)).

Why is this? Is this because we are building for 32bit not 64bit? Because upstream Arch was able to build firefox on 1.49 just fine.

After searching on the net, Mozilla apparently requires firefox to be built on the latest stable rust, which is 1.49 right now. So, if we get rust 1.49, then firefox ought to build just fine.

mistersmee · 2021-01-22 16:16:18

mistersmee wrote:

deep42thought wrote:
abaumann wrote:
You can temporarily add makedepends=('llvm10'), so that Rust still works, ...
:: llvm and llvm10 are in conflict. Remove llvm10? [y/N] 
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: llvm and llvm10 are in conflict
==> ERROR: 'pacman' failed to install missing dependencies.
nope, won't work - llvm and llvm10 cannot be installed along each other.
Maybe llvm10-libs will work?
It specifically provides libLLVM-10.so which is what rust and other programs are complaining about being missing.
And it doesn't conflict with llvm.
Btw, installing llvm10-libs fixed a host of little problems that I didn't even notice had come up on my system when llvm got upgraded to 11. mpv was able to use vdpau as output backend, which I hadn't realised was missing.
Maybe all the programs that depend upon llvm haven't caught on that llvm was upgraded to version 11?
Just like some python stuff is still stuck on python3.8.

And maybe add llvm10-libs as temporary makedepends for building both rust and firefox, as both had failed to build the last time citing

/usr/lib/libLLVM-10.so: no such file or directory

.

Last edited by mistersmee (2021-01-22 16:16:38)

abaumann · 2021-01-23 07:37:26

Yes, llvm10-libs makes an old rust run again, but usually you have to bootstrap a new rust.
rust 1.N only builds with rust 1.(N-1), so either we have to build all intermediate versions
up to 1.49 or we can shortcut this by using https://aur.archlinux.org/packages/rust-bin,
but this raises concerns about "trusting trust".

The efforts to keep firefox alive on 32-bit by building it from sources are just very high.

You can always download the binary version of firefox from the AUR
(https://aur.archlinux.org/packages/firefox-bin/).

See all the patching and workarounds needed to build firefox currently:

https://git.archlinux32.org/packages/tree/extra/firefox

And you need a very fast machine and hours of build time to get from one error to another.

Basically the problem is, that authors don't care at all anymore about 32-bit Intel, even
if you fix things, they sometimes don't see the need to intergrate it, most Linux distributions
are 64-bit only now.

levi · 2021-01-23 08:14:54

Yeah, it's just us and debian now pretty much. And we seem to be the only ones building i486 and pentium 4 packages.

I know rust's stance seems pretty onerous to us here, but aren't they doing things the same way that the original C compilers were brought up?

abaumann · 2021-01-23 08:46:46

Not at all:
- C can do incremental linking, rust still not
- a C compiler is roughly 100 times faster than the Rust compiler
- C has a minimalistic runtime, Rust has a huge runtime with micro-packages
- C is standardized in the ISO commitee, Rust is a defacto standard changing it's mind
from 1.(N) to 1.(N+1). They don't have a complete language report nor an up-to-date
grammar.
- C can be built without having a network, Rust (or better) cargo draws it's dependencies
from the net ("always connected anti-pattern")
- what's worse: Rust is not even a nice language, it looks over-complicated to be compared
to C++, rather have a look at Zig when you want to see a replacement for C/C++ (personal opinion here)

mistersmee · 2021-01-23 13:19:40

abaumann wrote:

Yes, llvm10-libs makes an old rust run again, but usually you have to bootstrap a new rust.
rust 1.N only builds with rust 1.(N-1), so either we have to build all intermediate versions
up to 1.49 or we can shortcut this by using https://aur.archlinux.org/packages/rust-bin,
but this raises concerns about "trusting trust".
The efforts to keep firefox alive on 32-bit by building it from sources are just very high.
You can always download the binary version of firefox from the AUR
(https://aur.archlinux.org/packages/firefox-bin/).
See all the patching and workarounds needed to build firefox currently:
https://git.archlinux32.org/packages/tree/extra/firefox
And you need a very fast machine and hours of build time to get from one error to another.
Basically the problem is, that authors don't care at all anymore about 32-bit Intel, even
if you fix things, they sometimes don't see the need to intergrate it, most Linux distributions
are 64-bit only now.

I see. So is this problem specific to Rust and therefore firefox, or does this apply to all humongous programs i.e. web browsers? I mean, is chromium the same?

Last edited by mistersmee (2021-01-23 13:36:26)

mistersmee · 2021-01-23 13:34:42

abaumann wrote:

You can always download the binary version of firefox from the AUR
(https://aur.archlinux.org/packages/firefox-bin/).

That is basically what I'm doing, just without pacman knowing it's there. However, I can notice performance differences a lot between a generic binary of firefox and the platform-specific optimisations arch64 and we do. It hits 100% cpu usage more often and for longer, and freezes up quite a lot more. Or hey, maybe that's just the effects of placebo on me.

Ehh...maybe it's time to (temporarily) switch to chromium after all. At least, while I'm on 32bit.

Last edited by mistersmee (2021-01-23 14:18:54)

mistersmee · 2021-01-23 13:42:18

levi wrote:

Yeah, it's just us and debian now pretty much. And we seem to be the only ones building i486 and pentium 4 packages.
I know rust's stance seems pretty onerous to us here, but aren't they doing things the same way that the original C compilers were brought up?

Yeah, that's all that is left of 32-bit linux overall. Debian, and therefore it's derivatives. Slackware and it's derivatives. A few other minor distros. And us. We're a dying breed.

Last edited by mistersmee (2021-01-23 14:19:48)

abaumann · 2021-01-23 14:58:42

Let me try a rust booststrap via rust-bin, I was successful in the past.
I'm just not that motivated currently. :-)

Bob Hill · 2021-02-02 08:58:58

FWIW, as well as Debian/Slackware/etc, openSUSE also still supports 32-bit.

The 32-bit openSUSE mirrors contain Firefox 85.0, so it is somehow do-able.

I really hope that the Rust/Firefox problems can be fixed in Arch Linux 32.

mistersmee · 2021-02-02 12:55:06

Yeah, I hope so too.
Although @Bob Hill, something to be considered is that all of those distros are massive compared to Arch 32. Open SUSE has quite a lot more developers working on it, we don't have that many. All of those distros officially support 32-bit, while Arch 32 is a community port of mainline Arch, which doesn't officially support 32-bit. I was recently reminded of this difference, when I looked at the Linux builds of Zoom. They provide 64 and 32 bit packages for Ubuntu, Debian and OpenSUSE. But even though Arch 32 exists, there is only a 64-bit build of Zoom for Arch.

Last edited by mistersmee (2021-02-02 12:55:29)

Bob Hill · 2021-02-11 14:55:25

Many thanks to all those who work on Rust and Firefox in Arch Linux 32 for making Firefox 85 available - much appreciated!

levi · 2021-02-11 17:16:35

Nice, I think firefox 85 includes some code to isolate newer supercookies in site-specific domains. Might be useful if you filtering solution isn't blocking everything you think it is. Although I don't know if it helps with facebook et al tracking people's visits to sites that include their icon generally in the share this article with people box. That's just an image fetched from their server, and if you're on facebook or whatsapp or using an oculus rift at the same time, they'll know what you're reading.

Bob Hill · 2024-07-13 11:06:57

Given that infrequent Firefox updates have become a fact of life in Arch Linux 32, might it be appropriate to take advantage of this situation by deliberately packaging only ESR releases (currently 128.0esr), which only come out about once a year, and are supposedly more stable?

Last edited by Bob Hill (2024-07-14 08:58:35)

Arch Linux

#1 2021-01-17 17:41:25

Firefox failing builds.

#2 2021-01-18 08:11:54

Re: Firefox failing builds.

#3 2021-01-19 07:42:37

Re: Firefox failing builds.

#4 2021-01-19 07:48:31

Re: Firefox failing builds.

#5 2021-01-19 09:17:43

Re: Firefox failing builds.

#6 2021-01-19 15:04:47

Re: Firefox failing builds.

#7 2021-01-20 18:33:11

Re: Firefox failing builds.

#8 2021-01-21 16:39:36

Re: Firefox failing builds.

#9 2021-01-22 13:54:21

Re: Firefox failing builds.

#10 2021-01-22 14:05:37

Re: Firefox failing builds.

#11 2021-01-22 16:16:18

Re: Firefox failing builds.

#12 2021-01-23 07:37:26

Re: Firefox failing builds.

#13 2021-01-23 08:14:54

Re: Firefox failing builds.

#14 2021-01-23 08:46:46

Re: Firefox failing builds.

#15 2021-01-23 13:19:40

Re: Firefox failing builds.

#16 2021-01-23 13:34:42

Re: Firefox failing builds.

#17 2021-01-23 13:42:18

Re: Firefox failing builds.

#18 2021-01-23 14:58:42

Re: Firefox failing builds.

#19 2021-02-02 08:58:58

Re: Firefox failing builds.

#20 2021-02-02 12:55:06

Re: Firefox failing builds.

#21 2021-02-11 14:55:25

Re: Firefox failing builds.

#22 2021-02-11 17:16:35

Re: Firefox failing builds.

#23 2024-07-13 11:06:57

Re: Firefox failing builds.

Board footer