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)
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)
890 bytes,
patch
|
mcsmurf
:
review+
standard8
:
approval-comm-beta+
|
Details | Diff | Splinter Review |
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
Comment 1•11 years ago
|
||
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
Reporter | ||
Comment 2•11 years ago
|
||
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.
Comment 4•11 years ago
|
||
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
Reporter | ||
Comment 5•11 years ago
|
||
@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
Comment 7•11 years ago
|
||
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
Comment 9•11 years ago
|
||
Nicolas Thierry-Mieg: Could you run ldd on Firefox 25 which corresponds to SeaMonkey 2.22. Thanks!
Comment 10•11 years ago
|
||
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.
Comment 11•11 years ago
|
||
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.
Comment 13•10 years ago
|
||
(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)
Comment 14•10 years ago
|
||
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)
Comment 15•10 years ago
|
||
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.)
Comment 16•10 years ago
|
||
"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
Comment 17•10 years ago
|
||
"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
Comment 18•10 years ago
|
||
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.
Comment 19•10 years ago
|
||
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.
Assignee | ||
Comment 20•10 years ago
|
||
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.
Assignee | ||
Comment 21•10 years ago
|
||
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).
Comment 22•10 years ago
|
||
(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>
Assignee | ||
Comment 23•10 years ago
|
||
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
Assignee | ||
Comment 24•10 years ago
|
||
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.
Assignee | ||
Comment 25•10 years ago
|
||
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
Updated•10 years ago
|
Component: General → Build Config
Assignee | ||
Comment 26•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Product: SeaMonkey → MailNews Core
Version: SeaMonkey 2.23 Branch → Trunk
Assignee | ||
Updated•10 years ago
|
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 27•10 years ago
|
||
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+
Assignee | ||
Comment 28•10 years ago
|
||
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).
Assignee | ||
Comment 29•10 years ago
|
||
Attachment #8362240 -
Attachment is obsolete: true
Attachment #8362652 -
Flags: review+
Assignee | ||
Comment 30•10 years ago
|
||
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
Assignee | ||
Comment 31•10 years ago
|
||
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?
Comment 32•10 years ago
|
||
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)
Comment 33•10 years ago
|
||
(Eh, SM 2.24 build1 is done already, so this may be too late indeed...)
Comment 34•10 years ago
|
||
(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 35•10 years ago
|
||
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?
Assignee | ||
Comment 36•10 years ago
|
||
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
status-thunderbird28:
--- → fixed
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•