User Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/15.0 Firefox/15.0a1 Build ID: 20120515030518 Steps to reproduce: freundt@fluch:pts/1:~> firefox XPCOMGlueLoad error for file /usr/local/firefox/libxul.so: /usr/local/firefox/libxul.so: undefined symbol: _ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE Couldn't load XPCOM. Actual results: Dynamic linking didn't succeed, as indicated above. Expected results: Firefox should have started.

I suspect your glibc is too old.

freundt@fluch:pts/1:~> /lib/libc.so.6 GNU C Library stable release version 2.10.1, by Roland McGrath et al. Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.5.0 20090913 (experimental). Compiled on a Linux >>2.6.30<< system on 2009-09-13. Available extensions: crypt add-on version 2.1 by Michael Glad and others Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>.

John, I don't quite remember, was it an intentional choice to deploy gcc45_0moz4 only for ESR17 builds?

(In reply to Mike Hommey [:glandium] from comment #4) > John, I don't quite remember, was it an intentional choice to deploy > gcc45_0moz4 only for ESR17 builds? We didn't end up using it at all, actually, because we found additional issues even with that compiler: https://bugzilla.mozilla.org/show_bug.cgi?id=813613#c38 We're using 0moz3 in other places.

(In reply to Ben Hearsum [:bhearsum] from comment #5) > (In reply to Mike Hommey [:glandium] from comment #4) > > John, I don't quite remember, was it an intentional choice to deploy > > gcc45_0moz4 only for ESR17 builds? > > We didn't end up using it at all, actually, because we found additional > issues even with that compiler: > https://bugzilla.mozilla.org/show_bug.cgi?id=813613#c38 > > We're using 0moz3 in other places. But is is an intentional choice not to deploy it on other branches?

(In reply to Mike Hommey [:glandium] from comment #6) > (In reply to Ben Hearsum [:bhearsum] from comment #5) > > (In reply to Mike Hommey [:glandium] from comment #4) > > > John, I don't quite remember, was it an intentional choice to deploy > > > gcc45_0moz4 only for ESR17 builds? > > > > We didn't end up using it at all, actually, because we found additional > > issues even with that compiler: > > https://bugzilla.mozilla.org/show_bug.cgi?id=813613#c38 > > > > We're using 0moz3 in other places. > > But is is an intentional choice not to deploy it on other branches? Correct. The only reason we were considering deploying it on ESR was to avoid compat breakage. AFAIK we never considered deploying it elsewhere.

(In reply to Ben Hearsum [:bhearsum] from comment #7) > Correct. The only reason we were considering deploying it on ESR was to > avoid compat breakage. AFAIK we never considered deploying it elsewhere. Then I think we should, because the compat breakage exists on other branches too. It's probably less of a problem because it's likely that the gtk/glib requirement is not going to be fulfilled on systems wher glibc is too old. And it's too late for 20. BUT, with the changes from bug 852950, the error message displayed when libraries are failing to load is more explicit, and it would be better to fail with a message about libgio not being present, or a libgio symbol not being there because the version on the system is too old, than the non-obviousness of the message about "_ZNSbItN4base20string16_char_traitsESaItEE4_Rep20_S_empty_rep_storageE" (which, if you look, *is* present), although arguably, we could document it. But switching to a compiler version that doesn't have the problem is simple enough IMHO.

This bug probably isn't relevant at this point...