Bug#1017979: mozjs91: FTBFS on armel with gcc 12: multiple definition of `__sync_fetch_and_add_4' etc.

[Simon McVittie]

Source: mozjs91
Version: 91.10.0-1
Severity: serious
Tags: ftbfs help
X-Debbugs-Cc: debian-***@lists.debian.org
Control: block 1017961 by -1

Versions of mozjs91 newer than 91.10.0-1 failed to build on the armel
buildds. I tried building 91.10.0-1 in an armel chroot on amdahl, and
that also fails, which makes me think that the root cause for the build
failure is the upgrade from gcc 11 to 12 as default compiler.

The final link fails with multiple definitions of the various atomic

/usr/bin/arm-linux-gnueabi-g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-invalid-offsetof -Wc++2a-compat -Wduplicated-cond -Wimplicit-fallthrough -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=coverage-mismatch -Wno-error=free-nonheap-object -Wno-multistatement-macros -Wno-error=class-memaccess -Wno-error=deprecated-copy -Wno-error=unused-but-set-variable -Wformat -Wformat-overflow=2 -Wno-psabi -fno-sized-deallocation -fno-aligned-new -g -O2 -ffile-prefix-map=/home/smcv/mozjs91-armel=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fomit-frame-pointer -funwind-tables -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libmozjs-91.so -o libmozjs-91.so /home/smcv/mozjs91-armel/debian/build/js/src/build/libmozjs-91_so.list -lpthread -Wl,-z,relro -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 -fstack-protector-strong -Wl,-rpath-link,/home/smcv/mozjs91-armel/debian/build/dist/bin -Wl,-rpath-link,/usr/lib /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a -Wl,--version-script,symverscript -Wl,-soname,libmozjs-91.so.0 -lm -latomic -lz -lm -ldl
(.text+0x0): multiple definition of `__sync_fetch_and_add_4'; /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94: first defined here
(.text+0x38): multiple definition of `__sync_fetch_and_sub_4'; /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94: first defined here

(etc.)

An example build log:
https://buildd.debian.org/status/fetch.php?pkg=mozjs91&arch=armel&ver=91.13.0-1&stamp=1661218081&raw=0

The same failure mode occurred when I tried to build mozjs102 with ARMv7
inline assembler disabled for #1017961.

(For completeness: 91.10.0-1 and 91.12.0-1 have an additional failure
reason involving undefined references to
std::type_info::operator==(std::type_info const&) const, but I believe
that was fixed in 91.12.0-2 by removing an obsolete patch. The latest
mozjs91 and mozjs102 do not have the obsolete patch and do not exhibit
the std::type_info errors.)

Assistance from fans of armel would be much appreciated. If we cannot get
mozjs102 to compile on armel, then gjs and the GNOME stack in general will
probably have to be removed from armel, similar to the way we temporarily
removed them from s390x between mid 2019 and mid 2020.

smcv

[Jeffrey Walton]

Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1786623
Control: affects -1 + src:mozjs102

Post by Simon McVittie
The final link fails with multiple definitions of the various atomic

(.text+0x0): multiple definition of `__sync_fetch_and_add_4'; /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94: first defined here

Reported upstream as https://bugzilla.mozilla.org/show_bug.cgi?id=1786623

Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248#c2 (and
more generally https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358).

Post by Simon McVittie
(For completeness: 91.10.0-1 and 91.12.0-1 have an additional failure
reason involving undefined references to
std::type_info::operator==(std::type_info const&) const, but I believe
that was fixed in 91.12.0-2 by removing an obsolete patch.)

Correction, it was fixed by a patch removing an obsolete workaround.
Reported as https://bugzilla.mozilla.org/show_bug.cgi?id=1786621 (but we
already have a patch for this, so it's an upstream bug but not a Debian bug)

Jeff

[Simon McVittie]

Post by Jeffrey Walton

Post by Simon McVittie
The final link fails with multiple definitions of the various atomic

(.text+0x0): multiple definition of `__sync_fetch_and_add_4'; /home/smcv/mozjs91-armel/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a(compiler_builtins-23c2fc8f8ef06d87.compiler_builtins.bdb7b41d-cgu.153.rcgu.o):/usr/src/rustc-1.59.0/vendor/compiler_builtins/src/arm_linux.rs:94: first defined here

Also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104248#c2 (and
more generally https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358).

Those are related, but seem like the opposite issue: I'm getting
a build failure because I somehow end up with two copies of
__sync_fetch_and_add_4, whereas those bugs are about having zero copies
of similar compiler-provided functions. We want exactly one copy :-)

Or are you saying that I'm getting these multiple definitions *because*,
unlike gcc-11, gcc-12 is automatically providing symbols like
__sync_fetch_and_add_4 in order to resolve those gcc bug reports?

In any case it seems to be possible to work around this by forcing gcc-11,
which is not great (toolchain maintainers dislike uses of a non-default
gcc) but arguably better than FTBFS.

smcv