855882 - XPCOMGlueLoad error for file libxul.so

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Sebastian Freundt]

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.

Comment 1

[Mike Hommey [:glandium]]

I suspect your glibc is too old.

Comment 2

[Sebastian Freundt]

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

Comment 4

[Mike Hommey [:glandium]]

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

Comment 5

[[e-mail] (:bhearsum)]

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

Comment 6

[Mike Hommey [:glandium]]

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

Comment 7

[[e-mail] (:bhearsum)]

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

Comment 8

[Mike Hommey [:glandium]]

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

Comment 9

[[e-mail] (:bhearsum)]

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