Bug#1001314: mozjs78: FTBFS on armhf

[Fabio Fantoni]

Source: mozjs78
Version: 78.15.0-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

Hi, as can be see in reproducible tests
(https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/mozjs78.html)
latest mozjs78 fails to build on armhf in both sid and testing.

https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/mozjs78_78.15.0-1.rbuild.log.gz

https://tests.reproducible-builds.org/debian/rbuild/bookworm/armhf/mozjs78_78.15.0-1.rbuild.log.gz

I spotted this after saw that this caused block of migration of many
other packages in ubuntu:
https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mozjs78

[Simon McVittie]

On Wed, 08 Dec 2021 at 09:41:29 +0000, Simon McVittie wrote:
> At a guess, perhaps the problem is that the mozjs build system is explicitly
> specifying -march=armv7-a when it should be something like
> -march=armv7-a+vfpv3 or accepting the compiler's default?

Looks like this might be the same issue fixed by
https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e

smcv

[Simon McVittie]

On Wed, 08 Dec 2021 at 20:11:55 +0000, peter green wrote:
> The default -march value on Debian armhf is "armv7-a+fp". You should
> *NOT* use "armv7-a+vfpv3" as that specifies the version of vfpv3
> with 32 double precision registers which is above the Debian baseline.

https://github.com/alexcrichton/cc-rs/commit/b2f6b146b75299c444e05bbde50d03705c7c4b6e
(which I have now applied to the copy of cc-rs in mozjs78) uses
"-march=armv7-a -mfpu=vfpv3-d16", which seems like a plausible encoding of
the minimum spec given in https://wiki.debian.org/ArmHardFloatPort and
https://wiki.debian.org/ArchitectureSpecificsMemo#Architecture_baselines
(ARMv7 with Thumb-2 and VFPv3-D16).

If I understand correctly, VFPv3-D16 refers to the version of vfpv3 with
only 16 registers, which is exactly what our armhf baseline guarantees
(and as you point out, some ARM CPUs with VFPv3 have more registers, but we
require our binaries to assume those extra registers are not available).
Am I getting this right?

(And yes, in answer to the obvious question, it's not ideal that mozjs78
vendors lots of Rust modules, but I'm not aware of a way to un-vendor them
in Mozilla's rather unique build system. Someone who knows Rust and/or mozjs
better is welcome to step in any time.)

smcv