1786623 - mozjs (Spidermonkey) 91 build fails with gcc 12 on ARMv5: multiple definition of `__sync_fetch_and_add_4' etc.

Status: UNCONFIRMED

(Core :: JavaScript Engine, defect, P5)

Description

[Simon McVittie]

Steps to reproduce:

Rebuilt previously-working mozjs (Spidermonkey) version 91.10.0-1 on Debian armel (ARMv5 softfloat) with gcc 12, where it had previously been built with gcc 11

Actual results:

A lot of warnings similar to these during link:

/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=/<<PKGBUILDDIR>>=. -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 /<<PKGBUILDDIR>>/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,/<<PKGBUILDDIR>>/debian/build/dist/bin -Wl,-rpath-link,/usr/lib  /<<PKGBUILDDIR>>/debian/build/armv5te-unknown-linux-gnueabi/release/libjsrust.a  -Wl,--version-script,symverscript -Wl,-soname,libmozjs-91.so.0  -lm  -latomic -lz -lm -ldl
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/12/libgcc.a(linux-atomic.o): in function `__sync_fetch_and_add_4':
(.text+0x0): multiple definition of `__sync_fetch_and_add_4'; /<<PKGBUILDDIR>>/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
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/12/libgcc.a(linux-atomic.o): in function `__sync_fetch_and_sub_4':
(.text+0x38): multiple definition of `__sync_fetch_and_sub_4'; /<<PKGBUILDDIR>>/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

Expected results:

Successful build.

Forcing use of gcc-11 and g++-11 works around this.

I did not see similar build failures on other architectures, only on ARMv5.

Comment 1

[Simon McVittie]

I also experienced Bug #1786621 during this build.

Comment 2

[Simon McVittie]

mozjs 102 also has this bug, in addition to Bug #1786619. (Again, forcing use of gcc-11 and g++-11 works around this bug, but I do not have a solution for Bug #1786619.)

Comment 3

[Mike Hommey [:glandium]]

This would seem to be a problem between rustc and gcc, both providing the _sync_fetch_and* symbols, one in libcompiler_builtins, and the other in libgcc. I don't think there's anything that can be done on our side here.

Comment 4

[Simon McVittie]

I don't think there's anything that can be done on our side here.

That's what I had feared. For now I'm forcing gcc 11 on armel, but obviously that's only a short term answer while I look into whether Bug #1786619 can be resolved. However, it's increasingly looking as though Debian's approach to mozjs (and hence gjs and GNOME) is going to have to be architecture-specific removal from armel, like we did for s390x for a while in the past when that architecture was compiling-but-broken.

I see firefox is already unavailable on armel, because it needs nodejs. The subset of Firefox that goes into mozjs doesn't need nodejs, but presumably nodejs' lack of support for ARMv5 is for basically the same reason as mozjs not working there (the lack of useful atomic operation intrinsics).