mozjs (Spidermonkey) 91 build fails with gcc 12 on ARMv5: multiple definition of `__sync_fetch_and_add_4' etc.
Categories
(Core :: JavaScript Engine, defect, P5)
Tracking
()
People
(Reporter: smcv, Unassigned)
References
(Blocks 2 open bugs)
Details
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.
Reporter | ||
Comment 1•2 years ago
|
||
I also experienced Bug #1786621 during this build.
Reporter | ||
Comment 2•2 years ago
|
||
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.)
Updated•2 years ago
|
Comment 3•2 years ago
|
||
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.
Reporter | ||
Comment 4•2 years ago
|
||
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).
Updated•2 years ago
|
Updated•2 years ago
|
Description
•