Bug 571172 will be checked in with shader validation not building on linux x86-64, because it exposed a problem in our buildslaves -- see bug 560894 comment 11. We need to get the build problem fixed and this enabled; enabling this is a matter of reverting the changeset that disabled it for x86_64.

Vlad, should this be beta3? Moving to betaN for now.

betaN is fine -- but note that there's no work to be done here other than reverting the commit; the actual issue that needs to be fixed is a releng issue in bug 578880.

I'm not entirely sure this is a releng issue; fixing the build machines to run a build that still may not run for a large number of people isn't an ideal solution. I pushed a re-enable ANGLE (and webgl) patch to try with the patches here: http://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/4ab2b3400659/reenable-angle-linux-x86_64 http://hg.mozilla.org/users/dbaron_mozilla.com/patches/raw-file/4ab2b3400659/webgl-linux-x86_64 pulled down the build, and ran objdump -T on the resulting libxul.so. This is the list of all symbols to be found in libstdc++; note that the offending one is: _ZNSo9_M_insertIdEERSoT_ which c++filt says is: std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)

Right, see bug 560894 comment 11. That symbol is versioned, presumably because of a bugfix or something that took place -- hence the explicit 3.4.9 version on it instead of 3.4. The basic problem is that we're using a version of g++ (from our own tools/binary dir) that requires a minimum version of libstdc++, and we're just assuming that the libstc++ provided by the system will cover it. If we want to use g++ 4.3.3, then we need to use a version of libstdc++ that 4.3.3 requires; I don't think there's really any way around that.

I mentioned this in bug 578880, I'll mention it here too. To avoid stdc++ fragility, we need to link with -static-libstdc++, but that requires recompiling the compiler with CXXFLAGS=-fPIC. Which we do for gcc 4.5, just a matter of Build/Release flipping that on now.

Is it possible the patch for bug 595112 will help this?

Don't think so -- different problem. -static-libstdc++ would help, though (assuming we linked in the correct version of libstdc++!)

We don't use ANGLE on any linux at all - morphing this bug.

g++/stdlibc++ mismatch is fixed

(In reply to comment #8) > We don't use ANGLE on any linux at all - morphing this bug. If ANGLE isn't used on Linux at all, the current summary doesn't seem to make sense either. Is it meant to be "Re-enable WebGL on Linux" instead?

no, joe misspoke. we use the shader translator portion of ANGLE, but not the gl-d3d bridge.

The following is probably breaking compatibility with RHEL 5.X, see Bug 621704 0000000000000000 DF *UND* 00000000000002b2 GLIBCXX_3.4.9 _ZNSo9_M_insertIdEERSoT_ std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double)

I didn't misspeak, someone misread! :) I changed it from "We don't use angle on x86_64 linux" to "we don't use angle on linux." :)

WebGL sill not working in 4.0b11. Check it out: http://learningwebgl.com/lessons/lesson01/index.html

please reopen the bug, with the nightly minefield i still cant see any webgl page on linux

@ Geza, Daniel, WebGL is enabled on Linux but only the NVIDIA binary driver is whitelisted. Run with the MOZ_GLX_IGNORE_BLACKLIST environment variable defined, if you want to un-block your driver, like this: MOZ_GLX_IGNORE_BLACKLIST=1 firefox but then be ready for crashes. I didn't realize until now that the release notes were linking to this bug, I will write to the release notes authors to change that.

Thanks Jacob! I had tried it with some examples and it worked with the ATI fglrx driver without problem, even with the Google Body Browser.

That's great to hear. We're working on whitelisting more drivers for Firefox 5.