Open Bug 1786621 Opened 5 months ago Updated 5 months ago

mozjs (Spidermonkey) 91 build failure on ARMv5 since gcc 12: undefined reference to `std::type_info::operator==(std::type_info const&) const'


(Core :: JavaScript Engine, defect, P5)

Firefox 91





(Reporter: smcv, Unassigned)


(Blocks 1 open bug)



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

Summary: mozjs (Spidermonkey) 91 build failure since gcc 12: undefined reference to `std::type_info::operator==(std::type_info const&) const' → mozjs (Spidermonkey) 91 build failure on ARMv5 since gcc 12: undefined reference to `std::type_info::operator==(std::type_info const&) const'

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.

Blocks: sm-meta
Severity: -- → S4
Priority: -- → P5

The patch that's being reverted here is from and was apparently a workaround for 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:

they wanted me to talk with the binutils people instead:

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

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

You need to log in before you can comment on or make changes to this bug.