Closed Bug 937035 Opened 11 years ago Closed 10 years ago

SeaMonkey/Thunderbird require at least GLIBCXX_3.4.9 although it should only require 3.4.8 as maximum (SeaMonkey does not run in ScientificLinux 5 as libstdc++ is too old)

Categories

(MailNews Core :: Build Config, defect)

x86
Linux
defect
Not set
normal

Tracking

(thunderbird28 fixed)

RESOLVED FIXED
Thunderbird 29.0
Tracking Status
thunderbird28 --- fixed

People

(Reporter: manschke, Assigned: mcsmurf)

References

Details

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131029 Firefox/17.0 (Nightly/Aurora)
Build ID: 20131030075327

Steps to reproduce:

Launch Seamonkey 2.22 on ScientificLinux 5 (probably the same on RHEL 5/CentOS 5)


Actual results:

Error Message: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found 


Expected results:

Seamonkey should start.

The reason is probably obvious: SM release notes system requirements state:  "libstdc++ 4.3 or higher" . The latest (still supported) version of ScientificLinux 5 has libstdc++-4.1.2 with GLIBCXX_3.4.8 .

Question: Is it possible to build SM 2.22 on the same platform as SM 2.21 (which works)?

Thank you!
Andreas
Errm, but where is the bug in this report?
The build requirements were raised, and it correctly opts out.
Flags: needinfo?(manschke)
Summary: SM 2.22 does not run on ScientificLinux 5 → SM 2.22 does not run on ScientificLinux 5 as libstdc++ is too old
I see that point, but the SeaMonkey Community page mentions: "... A bug can be about a defect in the software, a feature request or an idea of how to improve exiting functionality ..." and points to bugzilla.mozilla.org. I agree that this issue is not a bug in the technical sense, but for the users it is: The software does not work any more after applying it's security patch on a major Linux platform which is still supported. 
If it would be for SeaMonkey 3.0 we would say "Ok, new software, new requirements", but for a security patch? For us it means we have to delete SeaMonkey and move to Firefox and Thunderbird, which both will get future security updates on the ESR version 17. Would it be possible to maintain a SeaMonkey ESR based on 2.21?

Thank you and best wishes,
Andreas
Flags: needinfo?(manschke)
This may be a change/requirement coming from the Core side of the code, which is the backend shared with Firefox and Thunderbird. Even if your libstdc++/glibc issue was fixed for 2.22, you will find two releases later that you will no longer be able to build it given that you'll need Python 2.7.3, which to the extent of my knowledge CentOS 5 doesn't provide either.

Platform requirement inevitable change over time, and with the new rapid-release system introduced by Firefox, changes may come with /any/ release (SeaMonkey only retained its way of numbering with major.minor releases).

It is also my understanding that SeaMonkey doesn't have the resources to maintain a separate ESR branch, though this certainly would be desirable. As for Thunderbird, they in turn decided to only release from the ESR branches every 7 cycles to soften the blow of the rapid-release train. BTW, their 17.0.10 was the last release on that branch, users will have to go with 24.2 once it comes out.
1. Firefox 25 and Thunderbird 25 have the same requirements so I don't see why you think moving to Firefox/Thunderbird would work.

1a. FYI SeaMonkey 2.21 == Firefox/Thunderbird 24. SeaMonkey 2.22 == Firefox/Thunderbird 25.

2. Is there a ScientificLinux RPM for libstdc++ 4.3 that you can install?
Alternately see http://forums.mozillazine.org/viewtopic.php?f=23&t=2075033
@Andre Klapper, rsx11m, Philip Chee:

Thank you for spending your time on this topic. We will move to Firefox and Thunderbird, as they are still supported as ESR version 17.0.X .

The information about the current 17.0.10 being the last release on that branch is a little alarming, but I hope that RedHat will distribute version 24.2 ESR for RHEL5, which should have "Production 3 support" (including security updates) until 2017 .

We will mirgrate to RHEL/CentOS/ScientificLinux version 7 if it becomes available and perhaps return to SeaMonkey :-)

Have a nice time,
Andreas
I am on Centos 5 fully up to date, which should be very similar to the OP's SL5.
I wonder whether this may actually be a build problem. In previous SM versions (at least 2.19 and 2.20), the seamonkey binary did not a have any deps on libstdc++.so.6, while 2.22 has such a dep [1].
This is surprising because following the link [2] it seems that the build mozconfig that was used [3] has LDFLAGS="-static-libstdc++" .
I don't know why this flag would have resulted in no deps on libstdc++ up to 2.21 and then suddenly a dep in 2.22. 
Note that RHEL5 (and thus C5 and SL5) does have an rpm libstdc++44-devel-4.4.7-1.el5.x86_64 , which should provide static libstdc++ 4.4 for building 2.22.

[1]
[nthierry@localhost Seamonkey]$ ldd ./seamonkey-2.22.en-US.linux-x86_64/seamonkey
./seamonkey-2.22.en-US.linux-x86_64/seamonkey: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./seamonkey-2.22.en-US.linux-x86_64/seamonkey)
        linux-vdso.so.1 =>  (0x00007fffa59fd000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b0c7ceba000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b0c7d0d6000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ef0400000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b0c7d2db000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003eefc00000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b0c7d55e000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b0c7cc9c000)
[nthierry@localhost Seamonkey]$ ldd ./seamonkey-2.19.en-US.linux-x86_64/seamonkey
        linux-vdso.so.1 =>  (0x00007fff981fd000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b42e70c1000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b42e72dd000)
        libm.so.6 => /lib64/libm.so.6 (0x00002b42e74e2000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003eefc00000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b42e7765000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b42e6ea3000)
[nthierry@localhost Seamonkey]$

[2] ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/2.22/contrib/seamonkey-2.22.en-US.linux-x86_64.README

[3] http://hg.mozilla.org/build/buildbot-configs/file/default/seamonkey/linux64/comm-beta/release/mozconfig
Nicolas Thierry-Mieg: Could you run ldd on Firefox 25 which corresponds to SeaMonkey 2.22. Thanks!
As requested in comment 9, using firefox-25.0.1.tar.bz2:
[nthierry@localhost firefox]$ ldd ./firefox
        linux-gate.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xf7f85000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7f80000)
        librt.so.1 => /lib/librt.so.1 (0xf7f77000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00826000)
        libm.so.6 => /lib/libm.so.6 (0xf7f4d000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00913000)
        libc.so.6 => /lib/libc.so.6 (0xf7df0000)
        /lib/ld-linux.so.2 (0xf7fba000)
[nthierry@localhost firefox]$

So the libstdc++ dep is there as well.
I can't figure out where firefox keeps its archived older releases, so I can't check with an older version of FF to see if the dep was also absent.
Both Firefox 24.0 and 24.1.1 ESR have libstdc++.so.6 listed in their ldd output (testing the x86-64 builds), only SeaMonkey 2.21 does not (and 2.20 did neither). Also, Thunderbird 24.0.1 does link dynamically against libstdc++.so.6, thus SeaMonkey appears to be the odd case here.
(Quoting bug 956843)
>  $ /usr/local/seamonkey/seamonkey -editor %u
> /usr/local/seamonkey/seamonkey: error while loading shared libraries:
> libstdc++.so.6: cannot open shared object file: No such file or directory

Hmm, this looks slightly different in that libstdc++.so.6 apparently isn't found at all.

Dan, can you run ldd on your machine and post the output here?
Flags: needinfo?(a9)
dan@dan1 /usr/local/seamonkey $ ldd -v seamonkey
	linux-gate.so.1 =>  (0xf77b1000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf777a000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7775000)
	libstdc++.so.6 => not found
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7731000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7714000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7560000)
	/lib/ld-linux.so.2 (0xf77b2000)

	Version information:
	./seamonkey:
		libm.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libm.so.6
		libgcc_s.so.1 (GLIBC_2.0) => /lib/i386-linux-gnu/libgcc_s.so.1
		ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
		libdl.so.2 (GLIBC_2.1) => /lib/i386-linux-gnu/libdl.so.2
		libdl.so.2 (GLIBC_2.0) => /lib/i386-linux-gnu/libdl.so.2
		libstdc++.so.6 (GLIBCXX_3.4.9) => not found
		libstdc++.so.6 (CXXABI_1.3) => not found
		libstdc++.so.6 (GLIBCXX_3.4) => not found
		libpthread.so.0 (GLIBC_2.1) => /lib/i386-linux-gnu/libpthread.so.0
		libpthread.so.0 (GLIBC_2.0) => /lib/i386-linux-gnu/libpthread.so.0
		libc.so.6 (GLIBC_2.1) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.2) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
	/lib/i386-linux-gnu/libpthread.so.0:
		ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
		ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
		ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
		libc.so.6 (GLIBC_2.3.2) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.1) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_PRIVATE) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2) => /lib/i386-linux-gnu/libc.so.6
	/lib/i386-linux-gnu/libdl.so.2:
		ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
		libc.so.6 (GLIBC_PRIVATE) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.1) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
	/lib/i386-linux-gnu/libm.so.6:
		ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
		libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_PRIVATE) => /lib/i386-linux-gnu/libc.so.6
	/lib/i386-linux-gnu/libgcc_s.so.1:
		libc.so.6 (GLIBC_2.2.4) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.1.3) => /lib/i386-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.0) => /lib/i386-linux-gnu/libc.so.6
	/lib/i386-linux-gnu/libc.so.6:
		ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
		ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2
		ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
Flags: needinfo?(a9)
So, 2.23 needs libstdc++.so.6 like 2.22 did. Had you tried 2.22 before and it didn't run either while 2.21 did?

It appears that libstdc++ is a separate package with its own RPM (at least on openSUSE which I'm using). Did you install that package, and if it's an x86_64 system, did you install the respective i386 version as well? (alternatively, try the "contrib" 64-bit build from the mozilla.org site.)
"Did you install that package, and if it's an x86_64
system, did you install the respective i386 version as well?"
I googled libstdc++.so.6 but didn't find anywhere I could download it from. It was not in my Mint 16 Cinnamon repository or in the backports.

"So, 2.23 needs libstdc++.so.6 like 2.22 did. Had you tried 2.22 before and it didn't run either while 2.21 did?"
I am using 2.22.1, which runs with no problem. 2.23 refuses to open. Never tried 2.21

When I ldd seamonkey 2.22.1 it does not show that it is needing libstdc++.so.6
dan@dan1 /opt/seamonkey $ ldd -v seamonkey
	linux-vdso.so.1 =>  (0x00007fff1431d000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0c0cb11000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0c0c90d000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0c0c608000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0c0c304000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0c0c0ee000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0c0bd25000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f0c0cd49000)

	Version information:
	./seamonkey:
		libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
		libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
		libstdc++.so.6 (CXXABI_1.3) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.9) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libpthread.so.0:
		ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libdl.so.2:
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/usr/lib/x86_64-linux-gnu/libstdc++.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
		libgcc_s.so.1 (GCC_4.2.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.3) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libm.so.6:
		libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libgcc_s.so.1:
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

My specs:
Linux Mint 16 Cinnamon (64 bit), Quad core AMD A8-3870 APU with Radeon HD Graphics 6550D, 8GB DDR3, 1600MHz
"try the "contrib" 64-bit build from the mozilla.org site."
I tried the contrib at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/2.23/contrib/
It did run successfully.
The ldd on the contrib found libstdc++.so.6 in /usr/lib/x86_64-linux-gnu/libstdc++.so.6

dan@dan1 ~/Downloads/seamonkey2.23contrib $ ldd -v seamonkey
	linux-vdso.so.1 =>  (0x00007fffc07fe000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f92d3780000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f92d357c000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f92d3277000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f92d2f73000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f92d2d5d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f92d2994000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f92d39b8000)

	Version information:
	./seamonkey:
		libdl.so.2 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libdl.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
Ok, so in your case the 64-bit version of this library is available whereas the 32-bit version isn't, hence only the x86_64 builds run for you.

The general question of this bug report remains why that library is suddenly needed as a dynamic dependency while it wasn't until 2.21, and whether or not that change was intentional.
I've just found bug 904485 , which probably explains the issue. The seamonkey mozconfigs were changed starting at 2.22 to not use LDFLAGS="-static-libstdc++" .
And AFAICT that breaks things on RHEL5 and derivatives, because the dynamic libstdc++ available on these systems is too old.
Blocks: 904485
Yes, the static libstdc++ was removed as it caused build problems with the automated tests and also made it impossible for SeaMonkey to load the Java plugin. Actually we had problems with the build because we did _not_ use the compat module as errors about needing GLIBCXX_3.4.9 appeared in the build log files (see Bug 904485 Comment 0). As far as I see this, Mozilla products should only require GLIBCXX 3.4.8 symbols, it should not use 3.4.9 symbols. So this might be a real bug here in our compat code at http://mxr.mozilla.org/comm-central/source/mozilla/build/unix/stdc++compat/stdc++compat.cpp
So, to summarize: SeaMonkey currently does not run on systems that provide a libstdc++ with GLIBCXX_3.4.8 as maximum version, is that correct? Then this looks like a real bug to me.
Note we have an automated test in http://hg.mozilla.org/mozilla-central/annotate/fed681aea42d/config/config.mk#l833 from Bug 643690 which checks if resulting binary does not include GLIBCXX_3.4.9 or higher symbols. So not sure in this case, the automated tests should catch it if there are GLIBCXX_3.4.9 or higher symbols in the resulting build. Also see Bug 936790 on this, there such a test failure happened (and it was fixed).
(In reply to Frank Wein [:mcsmurf] from comment #20)
> Yes, the static libstdc++ was removed as it caused build problems with the
> automated tests and also made it impossible for SeaMonkey to load the Java
> plugin.

Note that there was a work-around that allowed the java plugin to work (reported in the relevant bugzilla entry, and it worked for me):
LD_PRELOAD=libstdc++.so.6 seamonkey

<snip>
> So, to summarize: SeaMonkey currently does not run on systems that provide a
> libstdc++ with GLIBCXX_3.4.8 as maximum version, is that correct?

Yes that is correct:
On rhel6 (where SM 2.23 x86_64 works):
$ rpm -q libstdc++ --provides | grep 3.4.[89] | grep 64
libstdc++.so.6(GLIBCXX_3.4.8)(64bit)  
libstdc++.so.6(GLIBCXX_3.4.9)(64bit)  
By comparison, on rhel5 (where SM does not start):
$ rpm -q libstdc++ --provides | grep 3.4.[89] | grep 64
libstdc++.so.6(GLIBCXX_3.4.8)(64bit)  

And we can see that SM 2.23 x86_64 requires 3.4.9 symbols (this command is run on rhel6): 
$ ldd -v seamonkey-2.23.en-US.linux-x86_64/seamonkey
	linux-vdso.so.1 =>  (0x00007fff805eb000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ef7800000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003ef7c00000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003efdc00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003ef7000000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003efd800000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003ef7400000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003ef6c00000)

	Version information:
	seamonkey-2.23.en-US.linux-x86_64/seamonkey:
		libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
		libpthread.so.0 (GLIBC_2.2.5) => /lib64/libpthread.so.0
		libstdc++.so.6 (CXXABI_1.3) => /usr/lib64/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4.9) => /usr/lib64/libstdc++.so.6
		libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib64/libstdc++.so.6
		libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.3.2) => /lib64/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
<snip>
Confirming and adjusting summary. Possibly there's something wrong in the build process how the seamonkey binary is linked.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: SM 2.22 does not run on ScientificLinux 5 as libstdc++ is too old → SeaMonkey requires at least GLIBCXX_3.4.9 although it should only require 3.4.8 as maximum (SeaMonkey does not run in ScientificLinux 5 as libstdc++ is too old)
Version: SeaMonkey 2.22 Branch → SeaMonkey 2.23 Branch
So, according to objdump -T seamonkey|c++filt (on SeaMonkey 2.23) these two symbols cause the 3.4.9 dependency:
00000000      DF *UND*  000001d6  GLIBCXX_3.4.9 std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<unsigned long long>(unsigned long long)
00000000      DF *UND*  000001d6  GLIBCXX_3.4.9 std::basic_ostream<char, std::char_traits<char> >& std::basic_ostream<char, std::char_traits<char> >::_M_insert<long long>(long long)

which should be covered by http://mxr.mozilla.org/comm-central/source/mozilla/build/unix/stdc++compat/stdc++compat.cpp as far as I see this. So maybe the seamonkey executable does not get linked to the compat lib as already mentioned.
I looked a bit at the log build log files, it might be that in the SeaMonkey case the binary does not  get linked (I hope I got the terminology right :) to the libstdc++compat.a file, maybe due to the different build rules file used in comm-central:
/builds/slave/c-cen-t-lnx/build/objdir/mozilla/_virtualenv/bin/python /builds/slave/c-cen-t-lnx/build/mozilla/config/expandlibs_exec.py --depend .deps/seamonkey.pp --target seamonkey --uselist --  /usr/bin/ccache /tools/gcc-4.5/bin/g++ -o seamonkey  -Wall [snip -W options] -gdwarf-2 [snip -f options] -std=gnu++0x -fno-tree-vrp -pthread -pipe  -DNDEBUG -DTRIMMED -gdwarf-2 -Os -freorder-blocks  -fomit-frame-pointer nsSuiteApp.o   -lpthread  -Wl,-z,noexecstack -Wl,-z,text   -Wl,-rpath-link,/builds/slave/c-cen-t-lnx/build/objdir/mozilla/dist/bin -Wl,-rpath-link,/usr/local/lib   -Wl,--whole-archive /builds/slave/c-cen-t-lnx/build/objdir/mozilla/dist/lib/libmozglue.a /builds/slave/c-cen-t-lnx/build/objdir/mozilla/dist/lib/libmemory.a -Wl,--no-whole-archive -rdynamic -L../../mozilla/dist/bin -L../../mozilla/dist/lib -ldl  /builds/slave/c-cen-t-lnx/build/objdir/mozilla/dist/lib/libxpcomglue.a  -ldl    

In contract the Firefox one:
/builds/slave/m-cen-lx-000000000000000000000/build/obj-firefox/_virtualenv/bin/python /builds/slave/m-cen-lx-000000000000000000000/build/config/expandlibs_exec.py --depend .deps/firefox.pp --target firefox --uselist --  /usr/bin/ccache /tools/gcc-4.7.3-0moz1/bin/g++ -m32 -march=pentiumpro -o firefox  -Wall [snip -W options] [snip -f options] -std=gnu++0x -pthread -pipe  -DNDEBUG -DTRIMMED -g -Os -freorder-blocks  -fno-omit-frame-pointer  nsBrowserApp.o   -lpthread  -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id   -Wl,-rpath-link,/builds/slave/m-cen-lx-000000000000000000000/build/obj-firefox/dist/bin -Wl,-rpath-link,/usr/local/lib   -L../../dist/bin -L../../dist/lib -ldl  /builds/slave/m-cen-lx-000000000000000000000/build/obj-firefox/dist/lib/libxpcomglue.a  -lrt -Wl,--whole-archive /builds/slave/m-cen-lx-000000000000000000000/build/obj-firefox/dist/lib/libmozglue.a /builds/slave/m-cen-lx-000000000000000000000/build/obj-firefox/dist/lib/libmemory.a -Wl,--no-whole-archive -rdynamic -ldl  ../../build/unix/stdc++compat/libstdc++compat.a
Component: General → Build Config
Attached patch Patch (obsolete) — Splinter Review
This should fix it. Needed to copy the rules from the mozilla-central to the comm-central config files so that it links the application with the stdc++ compat library too. This will also fix the bug in Thunderbird.
I tested this patch on the try server, ldd -v output confirms that it works:
./seamonkey:
[...]
                libstdc++.so.6 (CXXABI_1.3) => /usr/lib/i386-linux-gnu/libstdc++.so.6
                libstdc++.so.6 (GLIBCXX_3.4) => /usr/lib/i386-linux-gnu/libstdc++.so.6

And so does the command line:
/builds/slave/tb-try-c-cen-lx-00000000000000/build/objdir-tb/mozilla/_virtualenv/bin/python /builds/slave/tb-try-c-cen-lx-00000000000000/build/mozilla/config/expandlibs_exec.py --depend .deps/seamonkey.pp --target seamonkey --uselist --  /usr/bin/ccache /tools/gcc-4.7.3-0moz1/bin/g++ -m32 -march=pentiumpro -o seamonkey  [...] -ldl  /builds/slave/tb-try-c-cen-lx-00000000000000/build/objdir-tb/mozilla/dist/lib/libxpcomglue.a  -ldl --> ../../mozilla/build/unix/stdc++compat/libstdc++compat.a <-- (emphasis by me :)
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #8362240 - Flags: review?(Pidgeot18)
Product: SeaMonkey → MailNews Core
Version: SeaMonkey 2.23 Branch → Trunk
Summary: SeaMonkey requires at least GLIBCXX_3.4.9 although it should only require 3.4.8 as maximum (SeaMonkey does not run in ScientificLinux 5 as libstdc++ is too old) → SeaMonkey/Thunderbird require at least GLIBCXX_3.4.9 although it should only require 3.4.8 as maximum (SeaMonkey does not run in ScientificLinux 5 as libstdc++ is too old)
Comment on attachment 8362240 [details] [diff] [review]
Patch

Review of attachment 8362240 [details] [diff] [review]:
-----------------------------------------------------------------

::: config/config.mk
@@ +803,5 @@
> +
> +ifneq (,$(MOZ_LIBSTDCXX_TARGET_VERSION)$(MOZ_LIBSTDCXX_HOST_VERSION))
> +ifneq ($(OS_ARCH),Darwin)
> +CHECK_STDCXX = @$(TOOLCHAIN_PREFIX)objdump -p $(1) | grep -e 'GLIBCXX_3\.4\.\(9\|[1-9][0-9]\)' > /dev/null && echo 'TEST-UNEXPECTED-FAIL | check_stdcxx | We do not want these libstdc++ symbols to be used:' && $(TOOLCHAIN_PREFIX)objdump -T $(1) | grep -e 'GLIBCXX_3\.4\.\(9\|[1-9][0-9]\)' && false || true
> +endif

I think this if block isn't needed, it's the latter one. Hopefully, we'll be getting rid of comm-central/config/* in a few weeks anyway though :-)
Attachment #8362240 - Flags: review?(Pidgeot18) → review+
Oh...yeah, of course :) for the test we would have to call CHECK_STDCXX which is called by CHECK_BINARY which is called by something else (on mozilla-central). This is not worth it (would have to "import" quite some new code).
Attachment #8362240 - Attachment is obsolete: true
Attachment #8362652 - Flags: review+
Pushed: https://hg.mozilla.org/comm-central/rev/95c57fa13b41

Leaving open for aurora/beta (I think there's enough time left to fix this for SeaMonkey 2.24)
Target Milestone: --- → Thunderbird 29.0
Comment on attachment 8362652 [details] [diff] [review]
Patch for checkin

[Approval Request Comment]
Regression caused by (bug #): Bug 904485 in some way
User impact if declined: SeaMonkey and Thunderbird won't run on old Linux versions
Testing completed (on c-c, etc.): Works fine on comm-central
Risk to taking this patch (and alternatives if risky): Low risk, only adds a rule to config.mk that already exists for libxul in mozilla-central for a long time now

Probably too late for the beta/final release of SeaMonkey 2.24 though?
Attachment #8362652 - Flags: approval-comm-beta?
Attachment #8362652 - Flags: approval-comm-aurora?
Frank, the merge was yesterday, so this should be fixed on aurora already.
You'd have to request approval-comm-{beta,release}? for 2.25/2.24 now.
Flags: needinfo?(ewong)
(Eh, SM 2.24 build1 is done already, so this may be too late indeed...)
(In reply to rsx11m from comment #32)
> Frank, the merge was yesterday, so this should be fixed on aurora already.
> You'd have to request approval-comm-{beta,release}? for 2.25/2.24 now.

Release is being done (though with a bit of a repack issue) so unfortunately,
it's late for release.  If it's beta, it'll have to be 2.25b1.
Flags: needinfo?(ewong)
Comment on attachment 8362652 [details] [diff] [review]
Patch for checkin

Looks like this is already on aurora so a=Standard8 for beta
Attachment #8362652 - Flags: approval-comm-beta?
Attachment #8362652 - Flags: approval-comm-beta+
Attachment #8362652 - Flags: approval-comm-aurora?
Pushed: https://hg.mozilla.org/releases/comm-beta/rev/1ac8ffefb346

This bug should be fixed then in the next SeaMonkey release (2.25).
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.