Closed Bug 621704 Opened 14 years ago Closed 14 years ago

Lib dep problem: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by .../libxul.so)

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla6

People

(Reporter: koppel, Unassigned)

References

Details

(Whiteboard: [fixed in bug 643690])

Attachments

(2 files)

List of rhel 5.5 packages matching '*gcc*' and '*libstdc*'
2.81 KB, text/plain
Details
Info on repo libstdc++ packages
3.57 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b9pre) Gecko/20101227 Firefox/4.0b9pre
Build Identifier: The 28 December 2010 Linux x686 nightly build.

Firefox won't start, the following error message appears when trying to start it from a shell:

/extra/localpri/build/ff-mc-x/firefox-bin: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /extra/localpri/build/ff-mc-x/libxul.so)


This occurred after updating from the 27 Dec nightly.

Reproducible: Always

Steps to Reproduce:
1. Try to start firefox (Minefield) using the usual path to the firefox script.
2.
3.
Actual Results:  
Error message is printed, Firefox doesn't start.

Expected Results:  
The profile manager window should open up. 

uname -a
Linux orion.ece.lsu.edu 2.6.18-194.26.1.el5 #1 SMP Fri Oct 29 14:21:16 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

The previous nightly, Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b9pre) Gecko/20101227 Firefox/4.0b9pre ID:20101227030354, works fine.
Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20101228 Firefox/4.0b9pre

I just installed the nightly for the 28th and it works fine for me.

Linux dave-laptop 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

Could be that I'm on 32-bit and you're on 64-bit, though your UA says you're using the 32-bit version too even though the system is 64-bit.

Most likely thing might be that you're using a version of glibc that is too old for one reason or another. (check using "ldd --version") I'm using 2.11.1.
Version: unspecified → Trunk
Here's the output of ldd, and some other potentially useful info.

ldd --version
ldd (GNU libc) 2.5
Copyright (C) 2006 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.
Written by Roland McGrath and Ulrich Drepper.

BTW, I am up to date (for RHEL 5.x).  FWIW:

Loaded plugins: downloadonly, rhnplugin, security
Installed Packages
compat-glibc.i386                   1:2.3.4-2.26            installed           
compat-glibc.x86_64                 1:2.3.4-2.26            installed           
compat-glibc-headers.x86_64         1:2.3.4-2.26            installed           
glibc.i686                          2.5-49.el5_5.7          installed           
glibc.x86_64                        2.5-49.el5_5.7          installed           
glibc-common.x86_64                 2.5-49.el5_5.7          installed           
glibc-devel.i386                    2.5-49.el5_5.7          installed           
glibc-devel.x86_64                  2.5-49.el5_5.7          installed           
glibc-headers.x86_64                2.5-49.el5_5.7          installed           
Available Packages
glibc-utils.x86_64                  2.5-49.el5_5.7          rhel-x86_64-server-5

And: 

objdump -x /usr/lib/libstdc++.so.6

/usr/lib/libstdc++.so.6:     file format elf32-i386
[snip]
Version definitions:
1 0x01 0x025f4d66 libstdc++.so.6
2 0x00 0x08922974 GLIBCXX_3.4
3 0x00 0x02297f81 GLIBCXX_3.4.1
	GLIBCXX_3.4 
4 0x00 0x02297f82 GLIBCXX_3.4.2
	GLIBCXX_3.4.1 
5 0x00 0x02297f83 GLIBCXX_3.4.3
	GLIBCXX_3.4.2 
6 0x00 0x02297f84 GLIBCXX_3.4.4
	GLIBCXX_3.4.3 
7 0x00 0x02297f85 GLIBCXX_3.4.5
	GLIBCXX_3.4.4 
8 0x00 0x02297f86 GLIBCXX_3.4.6
	GLIBCXX_3.4.5 
9 0x00 0x02297f87 GLIBCXX_3.4.7
	GLIBCXX_3.4.6 
10 0x00 0x02297f88 GLIBCXX_3.4.8
	GLIBCXX_3.4.7 
11 0x00 0x056bafd3 CXXABI_1.3
12 0x00 0x0bafd171 CXXABI_1.3.1
	CXXABI_1.3
Confirm that 

2010-12-27-03-mozilla-central is last good
2010-12-28-03-mozilla-central is first bad

Problem reproduces here with OpenSUSE 10.2/32 Bit (I know, it's outdated since 2008). Problem has already been reported:

Bug 579186 - Mozilla-central N810 builds do not launch (GLIBCXX_3.4.9 not found)

The GCC on your target system is too old. As workaround you may compile a more recent gcc. Then LD_PRELOAD its libstdc++ when starting firefox.
(In reply to comment #3)
 
> The GCC on your target system is too old. As workaround you may compile a more
> recent gcc.

I could do that, but I fear I'll get drawn into an ever deepening install-missing-or-outdated-dependence time hole.
Blocks: 578877
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 578880
This is intentional. You may build Firefox yourself on your older system, but we do not intend for the Mozilla builds to continue supporting older systems such as this.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Do we know which particular version of gcc/libstdc++ is required for GLIBCXX_3.4.9, so we can mention that on our system requirements page?

(I'm assuming the symbol versions are a little different to gcc version numbers.)
Blocks: 586314
(In reply to comment #5)
> This is intentional. You may build Firefox yourself on your older system, but
> we do not intend for the Mozilla builds to continue supporting older systems
> such as this.

Older? RHEL 6, which presumably has a library that's new enough, was released November 2010.  There's no upgrade option so the only way for RHEL 5 users to get RHEL 6 is through a new install, so RHEL 5 will be around a while.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Which version of GCC does RHEL5 come with? We require the libstdc++ that comes with GCC 4.3. You will have to get Firefox from Redhat (or compile it yourself). We have made this decision in order to support newer features and focus our new releases on more modern compilers.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
(In reply to comment #8)
> Which version of GCC does RHEL5 come with? 

RHEL 5.x has gcc 4.1.2 as the default compiler but gcc 4.4.0 (yes, .0)
is available through yum and I have it installed. They both seem to
use the same stdc++, version 6.0.8 (based on the .so file name). See
Comment 2 for some more info.
Fedora's gcc package is split into several RPMs, one of which is libstdc++, and gcc-c++ depends on libstdc++.
http://koji.fedoraproject.org/koji/buildinfo?buildID=115326

Redhat may do something similar.
No longer blocks: 578880
(In reply to comment #10)
> Fedora's gcc package is split into several RPMs, one of which is libstdc++, and
> gcc-c++ depends on libstdc++.
> http://koji.fedoraproject.org/koji/buildinfo?buildID=115326
> 
> Redhat may do something similar.


Library libstdc++ is there, it's just too old. The RH package repo has
a newer version of gcc, which I have installed, but either that
doesn't update the shared library libstdc++.so.6 or the updated shared
library is still too old.

If there is an easy way to get Firefox working I'd like to know, and
that info would be good for the release notes. Otherwise, I'll wait
until there is time to install RH 6 or maybe Fedora.
Blocks: 578880
(In reply to comment #11)
Can you tell me where I can view information on RedHat's gcc packages, please?

Which rpm owns /usr/lib/libstdc++.so.6 and what versions of that rpm are available?
(In reply to comment #12)
> (In reply to comment #11)
> Can you tell me where I can view information on RedHat's gcc packages, please?

I'm not sure what you want. I'm going to attach a list of gcc and
libstdc++ entries found by yum (using a wildcard search).  That
list shows what I have installed.


> Which rpm owns /usr/lib/libstdc++.so.6 and what versions of that rpm are
> available?

Here is information on the libstc++ in /usr/lib:

    libstdc++-4.1.2-48.el5.x86_64 : GNU Standard C++ Library
    Repo        : installed
    Matched from:
    Filename    : /usr/lib64/libstdc++.so.6.0.8

    libstdc++-4.1.2-48.el5.i386 : GNU Standard C++ Library
    Repo        : installed
    Matched from:
    Filename    : /usr/lib/libstdc++.so.6.0.8

I don't know how to find the exact rpm file name.

  

  



    
    

    
  
Comment on attachment 501206 [details]
List of rhel 5.5 packages matching '*gcc*' and '*libstdc*'

> > Can you tell me where I can view information on RedHat's gcc packages, please?
> 
> I'm not sure what you want.

What would be helpful in determining whether there is an easy way to get mozilla builds of Firefox working on a RHEL 5 system would be info similar to
http://koji.fedoraproject.org/koji/buildinfo?buildID=115326 and the "info" links there for each package (but for RHEL5).

>Installed Packages
>libstdc++.i386                       4.1.2-48.el5           installed           
>libstdc++.x86_64                     4.1.2-48.el5           installed           
>libstdc++-devel.x86_64               4.1.2-48.el5           installed           
>libstdc++44-devel.i386               4.4.0-6.el5            installed           
>libstdc++44-devel.x86_64             4.4.0-6.el5            installed           

Thanks.
What I'm a bit surprised about here is that libstdc++44-devel.i386 hasn't pulled in a libstdc++44.i386.
The lists of files and dependencies of libstdc++44-devel.i386 may explain why that hasn't happened (or isn't necessary).

  

  



    
    

    
  
(In reply to comment #15)
> Comment on attachment 501206 [details]
> List of rhel 5.5 packages matching '*gcc*' and '*libstdc*'
> 
> > > Can you tell me where I can view information on RedHat's gcc packages, please?
> > 
> > I'm not sure what you want.
> 
> What would be helpful in determining whether there is an easy way to get
> mozilla builds of Firefox working on a RHEL 5 system would be info similar to
> http://koji.fedoraproject.org/koji/buildinfo?buildID=115326 and the "info"
> links there for each package (but for RHEL5).

I'll post the yum info.

> >Installed Packages
> >libstdc++.i386                       4.1.2-48.el5         installed           
> >libstdc++.x86_64                     4.1.2-48.el5           installed           
> >libstdc++-devel.x86_64               4.1.2-48.el5           installed           
> >libstdc++44-devel.i386               4.4.0-6.el5            installed           
> >libstdc++44-devel.x86_64             4.4.0-6.el5            installed           
> 
> Thanks.
> What I'm a bit surprised about here is that libstdc++44-devel.i386 hasn't
> pulled in a libstdc++44.i386.
> The lists of files and dependencies of libstdc++44-devel.i386 may explain why
> that hasn't happened (or isn't necessary).

The repo doesn't list a libstdc+44.i386, only the devel packages. The devel packages include a static library and that static library includes _ZNSo9_M_insertIdEERSoT_ aka std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<double>(double), which IIU Bug 578877 correctly, is the one missing function.  Perhaps all I have to do is create a shared library from the static archive. Or build firefox myself.

  

  



    
    

    
  


  

  

  



    
    

    
  
http://rpm.pbone.net/index.php3/stat/6/idpl/13942061/dir/centos_5/com/libstdc++44-devel-4.4.0-6.el5.i386.rpm
includes /usr/lib/gcc/i386-redhat-linux6E/4.4.0/libstdc++.so

and http://rpm.pbone.net/index.php3/stat/6/idpl/13944127/dir/centos_5/com/gcc44-c++-4.4.0-6.el5.x86_64.rpm
includes /usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/libstdc++.so
and /usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/32/libstdc++.so

Does including the appropriate directory/ies in LD_LIBRARY_PATH solve the problem?

I would have expected them to already be in /etc/ld.so.conf.
Are they there?

  

  



    
    

    
  
(In reply to comment #18)
> http://rpm.pbone.net/index.php3/stat/6/idpl/13942061/dir/centos_5/com/libstdc++44-devel-4.4.0-6.el5.i386.rpm
> includes /usr/lib/gcc/i386-redhat-linux6E/4.4.0/libstdc++.so
> 
> and
> http://rpm.pbone.net/index.php3/stat/6/idpl/13944127/dir/centos_5/com/gcc44-c++-4.4.0-6.el5.x86_64.rpm
> includes /usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/libstdc++.so
> and /usr/lib/gcc/x86_64-redhat-linux6E/4.4.0/32/libstdc++.so
> 
> Does including the appropriate directory/ies in LD_LIBRARY_PATH solve the
> problem?
> 

That libstdc++.so file contains a very short linker script:

  INPUT ( -lstdc++_nonshared /usr/lib64/libstdc++.so.6 )

Putting this file in the ff bin dir and renaming it libstdc++.so.6 does not work (ff gags on it). I'm not familiar enough with ld to know whether the dynamic linker can be made to use this linker script.  I did try to generate a shared library from the nonshared and older library, but encountered one problem or another. 

> I would have expected them to already be in /etc/ld.so.conf.
> Are they there?

The gcc 4.4 package is included as a preview, they probably kept the included libraries out of the default search path intentionally so as to not disturb builds which do not specifically intend to use gcc 4.4.

  

  



    
    

    
  
Ah, thanks.  I forgot that it was libstdc++.so.6 rather than libstdc++.so that was needed.

It looks like the 4.4 preview has been created (modified) in such a way that it works with the old libstdc++.so.6.

I don't really have any good suggestions for a simple solution.  Building firefox (with gcc44) definitely should work.  Extracting libstdc++.so.6 and probably libgcc_s.so.1 from a package for a more recent distribution and putting those files in a place referenced in LD_LIBRARY_PATH may work.

  

  



    
    

    
  
I have posted a solution to this for users of older libstdc++ libraries (e.g. Fedora 6, CentOS 4 or 5) to the Mozillazine forum here:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2075033

Basically, it involves installing a later libstdc++ library (I picked Fedora 9's, because it was earliest one that's easily downloadable) into your unpacked Firefox tree (and because Firefox's wrapper script sets LD_LIBRARY_PATH, it's used in preference to the system libstdc++ library).

  

  



    
    

    
  
Please reconsider the "RESOLVED WONTFIX" status of this issue. We have hundreds of users that won't be able to use firefox 4 without the hack to install a non-standard libstdc++ (with who knows what side effects); and we are not alone.

The whole idea of RHEL/CentOS/Scientific Linux/etc. 5.X is to use a stable distribution in an Enterprise environment so switching to 6.0 is a huge project that will take months, even years, for most installations. Meanwhile, we'll be stuck with an old firefox for that time and compatibility issues will eventually arise. RHEL/etc. 5.X is still being maintained and is heavily used in large organizations. Please fix this ASAP.

  

  



    
    

    
  
(In reply to comment #24)
> Please reconsider the "RESOLVED WONTFIX" status of this issue. We have hundreds
> of users that won't be able to use firefox 4 without the hack to install a
> non-standard libstdc++ (with who knows what side effects); and we are not
> alone.
> 
> The whole idea of RHEL/CentOS/Scientific Linux/etc. 5.X is to use a stable
> distribution in an Enterprise environment so switching to 6.0 is a huge project
> that will take months, even years, for most installations. Meanwhile, we'll be
> stuck with an old firefox for that time and compatibility issues will
> eventually arise. RHEL/etc. 5.X is still being maintained and is heavily used
> in large organizations. Please fix this ASAP.

Please see Bug 643690.

  

  



    
    

    
  
The binary distribution of Firefox provided by mozilla.org is not designed for these legacy environments. Because your OS is maintained by RedHat, you should really be asking them for RH5-compatible packages of Firefox 4.

  

  



    
    

    
  
Matt - adding the Fedora 9 libstdc++.so.6 library to the top level of the Firefox 4 binary tree hasn't caused any side-effects in the 2.5 months I've been doing it (later betas and Firefox 4 final). I see it as a temporary fix until CentOS 6 is released [hopefully within a month - it's sadly long overdue]. If you're using CentOS 5.5 on desktops like I am, I'm sure you'll be itching to deploy CentOS 6 on them ASAP, if only for the later versions of many desktop packages - plus the Firefox 4 binary package supplied by mozilla.org should run out of the box on CentOS 6.

bsmedberg - I can understand your stance on Firefox 4 vs. RHEL 5/CentOS 5, but it wasn't formally stated until just before Firefox 4 final came out (i.e. that's when the release notes page finally got updated with a libstdc++ 4.3.0 requirement). As far as I'm concerned, the requirements pages for both Firefox 3 and all Firefox 4 pre-final releases implied both 3.X and 4.X pre-final worked on CentOS 5.5 since that 100% satisfied the system requirements. Sadly, that wasn't the case :-( A slight ball-drop on the documentation front, but luckily a temporary workaround picked the ball up again nicely for CentOS 5.5 users.

  

  



    
    

    
  
(In reply to comment #5)
> This is intentional. You may build Firefox yourself on your older system, but
> we do not intend for the Mozilla builds to continue supporting older systems
> such as this.

 Just my 2 ct. I am working in environments where RHEL5.x or SLES10.x are just now rolled out for new server/workstation hardware. Those distributions will be around for quite some while. Not supporting them in the default binary will cost coverage for FF4/FF5.

Martin

  

  



    
    

    
  
> I am working in environments where RHEL5.x or SLES10.x are just
> now rolled out for new server/workstation hardware.

RHEL5.x EOL's on 31 Mar 2014 (as does CentOS 5) and SLES10 EOL's in July 2013, so you'll get just under 3 years for RHEL5 and just over 2 years for SLES10 before all regular support stops. Considering RHEL6 and SLES11 have been out for a while now, I think your environment's policy needs updating really.

> Not supporting them in the default binary will cost coverage for FF4/FF5.

I suspect very few new deployments will be using RHEL5 or SLES10 now, so the "coverage" will be tiny really. As I said in my earlier comment, the libstdc++ issue can be worked around without any side-effects (I haven't tried it on SLES10, but I suspect it would work) and when CentOS 6 comes out (should be soon), Firefox 4 and 5 will work out of the box on that too.

One curious issue though - I wonder if Mozilla themselves are using this libstdc++ workaround on their Linux build systems because the libc they use for their Linux binary build is from CentOS 5!

  

  



    
    

    
  
Just my 2¢. A byproduct of the work to get our toolchain upgraded to gcc 4.5 involved getting rid of the dependency on gcc 4.5's libstdc++. And as it was not very difficult to get rid of the dependency on gcc 4.3's libstdc++ as well, the same patch does that too. I landed it a few minutes ago on mozilla-central (bug 643690). This means Firefox 6 will work on these ancient systems.

AIUI, it's too late for Macaw (next Firefox 4 minor release), but it could be considered for Firefox 5, if the release drivers are okay with it.

  

  



    
    

    
  
(In reply to comment #30)
> I think your environment's policy needs updating really.

You may think, but he is certainly not the only one ... IIRC we got only last year majority of our customers on RHEL5.

  

  


Depends on: 643690
Resolution: WONTFIX → FIXED
Whiteboard: [fixed in bug 643690]
Target Milestone: --- → mozilla6

    
  
Product: Core → Firefox Build System

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: