Bug 214350 – emul-linux-x86-java-1.6.0.3: plugin dies with gcc-4.2.2's libstdc++

• Status: RESOLVED NEEDINFO
• Product: Gentoo Linux

[Description Clemens Fruhwirth 2008-03-23 09:01:45 UTC]

running 32-bit firefox 3.0b4 and emul-linux-x86-java-1.6.0.3 fails with the 32 bit c++ libraries compiled with gcc-4.2.2 at /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/32/libstdc++.so.6.0.9. 

When opening the first java applet in firefox, a sigsegv in

0xf1bc713d in JavaVM5::CreateRemoteJNIEnv () from /opt/emul-linux-x86-java-1.6.0.03/lib/i386/libjavaplugin_nscp.so

0xf1a71427 in CNSAdapter_NSPR::JDFileDesc_To_FD () from /opt/emul-linux-x86-java-1.6.0.03/plugin/i386/ns7/libjavaplugin_oji.so

is the result. I found that this can be workaround by downgrading to another libstdc++ version, namely 6.0.8 from 4.1.2 or even libstdc++.so.6.0.3 from gcc-3.4.6.

There are a few options to solve that: 
* emul-linux-x86-java could block on gcc-4.2*
* the other way round
* in the firefox launch scripts LD_LIBRARY_PATH could be set to redirect it to the correct libstdc++.

I tagged the bug 'minor' as gcc-4.2.2 is still masked.

[Comment 1 Clemens Fruhwirth 2008-03-27 11:07:50 UTC]

A nice quickfix for this is 

ln -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32/libstdc++.so* /opt/firefox
(3.4.6 works too)

the run-mozilla.sh script will add /opt/firefox to LD_LIBRARY_PATH so 4.1.2's libstdc++ takes precedence. 

Probably just add this to the firefox-bin ebuild?

[Comment 2 SpanKY 2008-12-07 20:25:42 UTC]

and does it fail with gcc-4.3.2 ?

[Comment 3 Petteri Räty (RETIRED) 2008-12-07 22:05:10 UTC]

There's also a rewritten plugin in the latest emul-linux-x86 packages (but it only works with FF3).

[Comment 4 Mark Loeser (RETIRED) 2009-05-16 20:44:47 UTC]

Is this still a problem with gcc-4.3?