Firefox not up-to-date, on 69.0.3, current is 71.0

[gerardr]

Hi!

The most recent package for Firefox on aarch64 is version 69.0.3, while the current release is 71.0. Did builds start failing, or is there some numeric limit in the retrieve function, or ???

Thanks for checking!

[graysky]

Your mirror is out of date ... it was pushed 6 days ago. https://github.com/archlinuxarm/PKGBUIL ... f44755ec7d

[moonman]

https://archlinuxarm.org/packages 69 is still current.
It must have failed to build for some reason.

[graysky]

$this->bbcode_second_pass_quote('moonman', 'h')ttps://archlinuxarm.org/packages 69 is still current.
It must have failed to build for some reason.

[mogwai]

It's probably due to out-of-memory issues on the builds for armv7h and below. During compilation of firefox on 32bit systems, at several stages it needs more than the complete 32-bit address range. So it's hitting an unsurpassable boundary of the architecture.
I'm assuming that a package version is only released if it can be successfully built on all supported architectures. So, in that case the armv7h build could be holding back the aarch64 build. But that's just my speculation.

I've been trying for several weeks now to compile firefox 70 and 71 for armv7h based on the most recent PKGBUILDs. All my attempts to build it in an armv7h (32bit) environment have failed, both on the physical hardware or on a qemu environment on x86_64 with 32GB of RAM. I've tried many tricks to reduce the memory usage. If you google around, you'll find lots of results for other 32bit distros as well; not only limited to arm as i686 builds suffer from the same problem.
The largest bottleneck now seems to be linking libxul.so. Using distcc will not help to solve that, since linking has to be done on the host machine, thus by definition limited by the 32bit address range.

The only realistic alternative is cross-compiling... Yesterday I've finally managed to cross-compile firefox 71 for armv7h on a x86_64 machine. But I can't yet run and test it on my raspberry pi 3 because the toolchain that I used (from the AUR) has a more recent glibc than the one in the archlinuxarm repositories... Ah well, more fiddling to be done in the next couple of days...

[graysky]

Which toolchain from the AUR did you use? I maintain the PKGBUILD that provides the official Arch ARM toolchain (https://archlinuxarm.org/builder/xtools/) which works fine the last time I used it (19-Nov).

[mogwai]

I'm using the "pure" cross-compiling toolchain, not the distcc-based one.
So it's this one (and related packages): https://aur.archlinux.org/packages/arm-linux-gnueabihf-gcc/
As mentioned, any distcc-based approach will still run into the 32bit memory limitations at link stage.

Anywat, it's my bad that I didn't check the libc dependency against the version in the official ARM repository.

Can you actually also use the xtools toolchain for "pure" cross-compilation? I have to admit that I didn't look into that. I had just assumed that xtools only had the minimum tools needed for distcc compilation, so no linker etc.

[graysky]

I have always used the distcc toolchain and never experienced a problem.

[mogwai]

Indeed, the xtools toolchain contains everything that's needed to compile straight from x86_64 (e.g. linker etc.). My bad!
I'm now recompiling using this chain. I'm halfway through, and it's still looking good.

NB: I'm building everything from x86_64, so not through distcc from an arm host. I've tried that route for many days, but it always runs out of memory during the linking phase which can exclusively be done on the arm host. It simply looks like certain programs are becoming too big to compile/link on 32-bit hosts.

[gerardr]

Looks like the new version 72.0 builds successfully, as it now shows up in pacman.

I had a similar experience, as I successfully built an aarch64 version of 72.0 on a chromebook with 4GB of RAM but essentially setting the parallel make off by including 'mk_add_options MOZ_MAKE_FLAGS=-j1' in the '.mozconfig' file.