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).

The other build failure that I mentioned is #1786623.

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.

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.

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?

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)

Submitted https://github.com/unicode-org/icu/pull/2539