mozjs (Spidermonkey) 91 build failure on ARMv5 since gcc 12: undefined reference to `std::type_info::operator==(std::type_info const&) const'
Categories
(Core :: JavaScript Engine, defect, P5)
Tracking
()
People
(Reporter: smcv, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
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:
Several undefined references like this:
/usr/bin/ld: /<<PKGBUILDDIR>>/debian/build/js/src/build/../../../config/external/icu/common/rbbi.o: in function `std::type_info::operator!=(std::type_info const&) const':
/usr/include/c++/12/typeinfo:115: undefined reference to `std::type_info::operator==(std::type_info const&) const'
Expected results:
Successful build.
The attached patch avoided this particular aspect of the build failure (there was another, unrelated build failure which I will report separately).
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
The other build failure that I mentioned is #1786623.
Comment 2•2 years ago
|
||
SpiderMonkey is supposed to be compiled without exception enabled. Having errors about type_info
suggests that some part of the code might accidentally rely on type_info
where we have no desire to do so.
I guess this might be a question to raise to GCC / ICU components.
Reporter | ||
Comment 3•2 years ago
|
||
The patch that's being reverted here is from https://github.com/unicode-org/icu/commit/bd3131899f2443215a535ecfde3d380db9ed0074 and was apparently a workaround for https://bugs.llvm.org/show_bug.cgi?id=13364. I don't know why it's causing a build failure in mozjs but not in Debian's separate copy of ICU: possibly because mozjs is compiled without exceptions enabled?
Debian's Firefox packaging seems to have the same patch applied.
If we switched from using the bundled ICU to a system copy of ICU, that would probably work around this.
hi there, I've hit most likely the same bug with gcc-12.1.0 and reported it to the gcc people: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105601
they wanted me to talk with the binutils people instead: https://sourceware.org/bugzilla/show_bug.cgi?id=29149
the build failure is indeed triggered by using the internal icu copy, --with-system-icu works around the issue perfectly.
Comment 5•2 years ago
•
|
||
The reason why it happens in mozjs but not the separate copy of ICU is hidden visibility. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106633
So what is the best plan to take action with this?
Talk with upstream icu and ask them to revert the old workaround, and then patch up the internal icu copy of the firefox tree? And all affected distros who don't compile mozjs against system-icu can pull in the patch until its included in a new major icu release?
Comment 7•2 years ago
|
||
https://bugs.llvm.org/show_bug.cgi?id=13364 was an issue with a specific old version of libstdc++ that hasn't been around for years. The workaround could either be removed, or put in a #ifndef _GLIBCXX_RELEASE
(_GLIBCXX_RELEASE
was added in libstdc++ 7.0, which is more recent than the broken versions)
Comment 8•1 year ago
|
||
Updated•6 months ago
|
Description
•