Closed Bug 204236 Opened 22 years ago Closed 22 years ago

linux builds statically linking libstdc++ with licensing issues

Categories

(SeaMonkey :: Build Config, defect, P2)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.4final

People

(Reporter: dmosedale, Assigned: granrosebugs)

References

Details

(Whiteboard: [adt1])

In the course of upgrading the build machines to 2.95.3, we've inadvertantly started linking statically with libstdc++ from that version, which we had decided earlier (in bug 79681) had some license issues which would make us uncomfortable doing that. It seems to me that we have a bunch of options here, in particular a) Try again to get the FSF to state that the relevant code in 2.95.3 is under the exception mentioned in <http://bugzilla.mozilla.org/show_bug.cgi?id=79681#c27>. If this actually works, this is may be the best option, since it involves no code changes at this late date. b) If the FSF still won't answer their email, assume the risk associated with doing nothing and leaving things as they are. This doesn't seem to like a lot of risk to me, but, of course, I Am Not A Lawyer. c) Rebuild the build machine copies of 2.95.3 to allow dynamic linking with libstdc++. This will probably mean the builds will run on a significantly smaller number of machines out-of-the-box than they do now, possibly including all Red Hat boxes. This could perhaps be mitigated by providing a link to an RPM of the dynamic libstdc++ from 2.95.3 on the download page. d) Switch to gcc 3.2.x now. I've been given to understand, though I haven't verified myself, that static linking libstdc++ under gcc 3.2.x is legally OK. My understanding is also that at least one Netscape person has gotten various commercial bits playing nice with 3.2.x, so the fact that the build machines do double duty for Mozilla and Netscape builds shouldn't be a problem. Additionally, this isn't as untested as it sounds: I believe blizzard has been shipping gcc 3.2.x built RPMs for a while now, and, as far as I'm aware, without incident.
Flags: blocking1.4b?
Flags: blocking1.4?
The latter, please! We've been talking about it for long enough, and we get the 7-10% speed boot by being able to use -O2. (GCC-3.3 is out RSN; I don't recommened moving to that for a while, although if we go static then it shouldn't be as much of an issue as this move since the c++ ABI is teh same)
When building gcc-3.2 (the compiler itself, not _with_ 3.2), make sure to follow: http://gcc.gnu.org/gcc-3.2/c++-abi.html so that our builds are compatable with the rest of the world.
Priority: -- → P3
Target Milestone: --- → mozilla1.5beta
option e) go back to RedHat 6.2 and egcs.
Flags: blocking1.4b? → blocking1.4b-
Flags: blocking1.4? → blocking1.4+
isn't this basically a duplicate of bug 158387?
no, this is regarding the licensing issues around using 2.95.3 and libstdc++-v2 that we're using for mozilla 1.4f. That bug is on technical issues influencing the decision of what version of gcc 3.x to use for future releases at some future date. I'm working with our legal people to resolve this, but I'm hoping that this won't be a problem based on http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html talking about the binary exception for libstdc++-v3 and http://gcc.gnu.org/ml/libstdc++/2001-06/msg00370.html talking about the intent for -v2.
Severity: major → critical
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: mozilla1.5beta → mozilla1.4final
Any progress on doing one of these? This is a 1.4 release blocker!
We may be upgrading to gcc 3.something, work is still underway on this problem.
for the record, had a conference call today with relevant parties. current plan is that cls will check if the gcc 2.95.3 files were updated on the tip of the 2.95.3 branch. if so, we're holding off til after 1.4 to switch compilers. keep your fingers crossed that this is the case. if not, we're going to gcc 3.2.3 and either statically linking in the libstdc++ library or doing it dynamically and putting a pointer to an rpm in the release notes for people not running RH8. leaf is working on a test build so we can test the rest of the plugins and do a smoketest. known issues: - current JRE won't work with 3.2.3, need 1.4.2 beta (discussion in Sun's bugs 4694590 and 4687814 about this stuff - thanks Rick)
Suns stuff works with 1.4.1, I thought. It also works with blackdown's java builds. That option will work for moz.
No, Sun's 1.4.1 version does NOT come with a plugin compiled with gcc-3. Sun's 1.4.2beta and Blackdown's version are the only alternatives with a gcc-3.x-compiled Mozilla.
2.95.3 is not an option. we're now pursuing gcc 3.2.3 builds with due haste.
Please don't switch to gcc-3.x now, since this will **** off the last remaining Solaris users of Mozilla. There have been enough hassles with additional software requirements, OS patches, and bleeding edge library versions. Requiring to install a BETA version of java now will surely alienate anyone who was not tired yet using that platform with Mozilla....
adt: nsbeta1+/adt1
Keywords: nsbeta1+
Whiteboard: [adt1]
we have a mozilla build that is being smoketested: http://ftp.mozilla.org/pub/mozilla/nightly/2003-06-11-14-1.4-gcc323/mozilla-i686-pc-linux-gnu-installer.tar.gz the bug tracking changes required for the commercial build is 28819.
Just a question for "beanladen" you mention the Solaris users of mozilla.....Most of the Mozilla builds I know of (including my own) are built using the Sun CC compiler (Forte, Workshop, Sun One, Whatever) so as long as you have libc.so you should be just fine. GCC has absolutely no bearing on the Solaris users I know.
Oh yes, I just learned that this will instead force Linux users to either use the Blackdown or Sun's 1.4.2 Beta java. If that also means that Linux users MUST have a gcc 3.x compiled system, this will be not an option.
Reply to Donnie Cranford ... I'm a Solaris user of Mozilla. None of the Sun CC compiled Mozillas work on my machine. We do not have admin privileges for my machine. We do not have a Mozilla-friendly (or even Open Source-friendly) set of system admins. We can not download and install official patches. I can not use Roland Mainz's gcc/Solaris build of Mozilla, since he insists on including the XPrint code (which does not work on our machines "out of the box") and excluding the PostScript driver (which works fine). Hence I need to build my own copy. I have downloaded and built gcc 2.95.3. I have also downloaded Sun's version of Netscape 7 and squirrelled away the dynamic libraries I need. Ditto Sun's Java plugin which works with gcc 2.95.3 compatible binaries. I now build Mozilla (latest is 1.4b) from the src.tar.bz2 that are released and install in my home area for others to use. So, on the one hand, I am one of these mythical Solaris users of gcc 2.95.3. However, none of the publically providied Solaris builds of Mozilla work on our systems anyway, so we are resigned/accustomed to building our own. I've no axe to grind with Mozilla.org moving to gcc 3.2.x versions of Mozilla (and when Sun release a Java plugin compatible with gcc 3.2.x, I'll be moving up myself!), but please at least make sure that Mozilla will continue to be compilable by gcc 2.95.3, even if the publically-provided binaries do not do so ...
now that we have resolved 2.95.3 is not an option and we're going with gcc 3.2.3, should this bug be resolved as a dup of 158385?
Trying to run the installer at http://ftp.mozilla.org/pub/mozilla/nightly/2003-06-11-14-1.4-gcc323/mozilla-i686-pc-linux-gnu-installer.tar.gz on a RedHat 7.3 system results in "error while loading shared libraries". I happen to have a locally compiled gcc 3.2.1 lying around under /usr/local/lib and having /usr/local/lib in /etc/ld.so.conf (which is not the default). With that, I can run the build. However, no check is being made that I have the 3.2.3, it just uses my 3.2.1. The build appears to run and work. But as expected, the latest non-beta Java plugin does not work. Question: Would it make sense to continue to provide egcs compiled builds in addition?
turns out that build wasn't statically linking libstdc++, we're doing a new build now. anyone who wishes to is welcome to provide egcs 1.12 or gcc 2.95.3 builds to mozilla, but the Netscape build team has to do 3.2.3 builds and we don't have time to spare at this point to look at other compilers.
So again the number of users who can run Mozilla out of the box continues to shrink...
leaf has run into problems getting the 1.4 branch to compile with gcc 3.2.3 on RH7.3 and statically linking libstdc++. Next step is to try building with gcc3.2.3 on RH8. If that doesn't work, we'll need to go back to the drawing board and rethink our options.
I'd reccommend against RH8, for the simple reason that whilst libc is forard compat (so the build will run on RH9), its not backwards compat, so it won't run on people's RH7 systems. RH8 uses glibc-2.9x, so it'll then effectivly add a glibc2.3 requreiment to the binary. I don't think that you want that. What RH7 problems were you having?
beanladen, Graham Hudspith: If I get this correctly, it 1) won't affect what compiler can be used to build Mozilla, and 2) it will only affect pre-compiled builds for Linux, and not for any other platform. This all means, it won't affect Solaris in any way. You can use the same pre-compiled builds and you can use the same compilers there. Even on Linux, it doesn't affect people who build Mozilla their own, but only pre-compiled binaries. Developers, correct me if I'm wrong.
*** Bug 209279 has been marked as a duplicate of this bug. ***
bugzilla bug 205360 added the -lc option which is causing our problems building on gcc 3.2.3. we're doing a test build now removing -lc. reopened 205360 since it's a 1.4 blocker to make sure both these get fixed.
Depends on: 205360
Linux Distros with GCC>=3.2 (from distrowatch.com): Mandrake: 9.1 (current), 9.0 (released 2002/09/25) Red Hat: 9 (current), 8.0 (released 2002/09/30) SuSE: 8.2 (current), 8.1 (released 2002/09/30)
Gentoo GNU/Linux uses gcc 3.2.2 on stable tree and gcc 3.2.3 on testing tree. Gcc 3.3 is available to install also on the hardmasked tree but preparations are being made before it can be rolled out officially.
Slackware 9.0 (released on March 19, 2003) uses 3.2.2 as well. The -current tree is using 3.2.3 since May 21. I'm off to download and try one of the 3.2 builds.
we have test builds statically linking libstdc++. there is a new requirement of glibc 2.2.4 or higher, so if you're running 7.0-7.2 and you don't keep up with the errata, you'll need to install the latest. http://ftp.mozilla.org/pub/mozilla/nightly/2003-06-16-18-1.4/mozilla-i686-pc-linux-gnu-installer.tar.gz
I did not download the installer, but the full build tar.gz. I can run that build successfully on my up-to-date RH 7.3 system. Java 1.4.1 does not work. I downloaded Java 1.4.2 beta 2, and the contained ns610-gcc32 appears to work fine. But when trying to do Java based online banking, the application crashes completely. This is something that works for me correcely with egcs based Mozilla and the 1.4.1 Java plugin.
There is an error message on the console: INTERNAL ERROR on Browser End: Plugin instance index out of bounds 13376. System error?:: Resource not available
At least the build mentioned in this bug does not run on a RH 7.2 system, I just verified. However, Leaf told me that Brian was able to get a compatible build on another machine. If you want me to test that, please let me know.
Please note: I am able to use the version of egcs 1.1.2 that was shipped with RH 7.3, and compile Mozilla binaries on that RH 7.3 system that run on the RH 7.2 just fine. I suspect those binaries run on some earlier versions, too. And that binary works correctly with stable Java 1.4.1. I will have binaries available tomorrow for you to test.
The binary compiled with RH 7.3's egcs 1.1.2 also runs on RH 9. RH 9's package compat-libstdc++-7.3-2.96.118 contains the required /usr/lib/libstdc++-2-libc6.1-1-2.9.0.so
Note, I'm using a trick to make sure, when compiling on RH 7.3 with egcs, that no part of the build system uses another system installed compiler. Confusion is easy, because egcs is installed as egcs++ and egcs, while gcc and g++ point to gcc 2.96. I have create a directory /usr/local/egcs that contains the following links: c++ -> g++ cc -> gcc g++ -> /usr/bin/egcs++ gcc -> /usr/bin/egcs I learned this is better than using the build system's variables to use a different compiler. In particular because of NSS, which seems to fall back to gcc whatever is specified. (This was true in the past, not sure if that is still valid).
I've uploaded a full (non-install) build to www.kuix.de/misc/testmoz14.tar.gz using the build environment I outlined above. I managed to find someone with a plain RH 7.0 system. That system was still running glibc 2.1.92-14, the original glibc that came with 7.0. No compiler has ever been compiled on that system. It was able to run the above binary, it converted an older netscape profile and loaded www.cnn.com fine. That was on an i486 machine with 32 MB of ram, over a remote X display tunneled through ssh.
kaie: was that an opt build? The thing which moved this all forward was that -O caused gcc to segfault. It may have only happened when built with symbols, or --enable-debug, or something like that. symbols are required for talkback, though. Can't find a bug on it now. Does java still segfault if you grab /lib/libgcc_s.so* from RH9, and stick it in /lib on your RH7 box?
is somebody working with sun/blackdown to get a 1.3.x build of java or something that doesn't require the specific term in the license agreement stating that you surrender the right to let sun download and install software to your computer? i will not install java builds later than the 1.3 series. i hope this doesn't mean i am blocked from using java in mozilla. see J2RE 1.4.1 License, Supplemental License Terms 5 and 6: <ftp://ftp.tux.org/pub/java/JDK-1.4.1/i386/01/LICENSE-j2re> 5. Notice of Automatic Software Updates from Sun. You acknowledge that the Software may automatically download, install, and execute applets, applications, software extensions, and updated versions of the Software from Sun ("Software Updates"), which may require you to accept updated terms and conditions for installation. If additional terms and conditions are not presented on installation, the Software Updates will be considered part of the Software and subject to the terms and conditions of the Agreement 6. Notice of Automatic Downloads. You acknowledge that, by your use of the Software and/or by requesting services that require use of the Software, the Software may automatically download, install, and execute software applications from sources other than Sun ("Other Software"). Sun makes no representations of a relationship of any kind to licensors of Other Software. ...
> kaie: was that an opt build? Yes, -O --enable-optimize="-O -g" --enable-crypto --disable-tests --disable-debug --enable-elf-dynstr-gc --disable-logging --without-system-nspr --without-system-zlib --without-system-jpeg --without-system-png --without-system-mng > The thing which moved this all forward was that -O caused gcc to segfault. It > may have only happened when built with symbols, or > --enable-debug, or something like that. symbols are required for talkback, > though. Can't find a bug on it now. egcs does not segfault for me I guess the files in my build tree have symbols, because I built using -g. And I have used egcs for all my Linux development work during the last 2 years, including all my Linux debugging. > Does java still segfault if you grab /lib/libgcc_s.so* from RH9, and stick > it in /lib on your RH7 box? I think our users should not be required to do such fiddling to their system. Some might not have root rights.
release builds are built with /configure --disable-tests --enable-extensions=default,irc --without-system-nspr --without-system-jpeg --without-system-zlib --without-system-png --without-system-mng --disable-debug --enable-optimize --disable-elf-dynstr-gc --enable-crypto --with-dist-prefix=/builds/client/linux22/seamonkey/mozilla/dist --with-mozilla --cache-file=.././config.cache --srcdir=.
the glibc requirement comes from the installation failing (bugzilla 180810) and then if you get it installed and run on a non-glibc225 system you get: ./mozilla-bin: /lib/i686/libc.so.6: version `GCC_3.0' not found (required by /u/granrose/communicator/linux/2003061707-1.4/libmozjs.so) ./mozilla-bin: /lib/i686/libc.so.6: version `GCC_3.0' not found (required by /u/granrose/communicator/linux/2003061707-1.4/libplds4.so) ./mozilla-bin: /lib/i686/libc.so.6: version `GCC_3.0' not found (required by /u/granrose/communicator/linux/2003061707-1.4/libplc4.so) ./mozilla-bin: /lib/i686/libc.so.6: version `GCC_3.0' not found (required by /u/granrose/communicator/linux/2003061707-1.4/libnspr4.so) I'm open to suggestions on how to resolve this in such a way that glibc 2.2.5+ isn't required.
Also note that scriptable plugins like Flash are not updated to be scriptable under gcc3 yet and Java 1.4.2 is only in beta. Anyone accessing XPCOM from native code could be effected by this. Since this bug sounds like it was caused by upgrading to 2.95.3, would it be possible to just go back to whatever we used in the previous release, at least for 1.4?
> Since this bug sounds like it was caused by upgrading to 2.95.3, would it be > possible to just go back to whatever we used in the previous release, at least > for 1.4? For previous releases, we were using egcs 1.1.2 Using gcc 2.95.3 was not possible, so gcc 3.2.3 was considered. gcc 3.2.3 causes the compatibility problems. I'm suggesting to stay == go back to egcs 1.1.2, to stay compatible.
I was successfully able to produce a build using the build options Jon posted in comment 41, with the minor difference: I used --enable-optimize="-O" to only use stable optimization in egcs. --with-dist-prefix=/builds/client/linux22/seamonkey/mozilla/dist --srcdir=. These are just driving where the build tree lives and don't influence the generated code.
I agre that requireing users to copy libgcc over isn't a solution, but if that fixes it then it shows what the problem is... Please try it, just for diagnostic purposes. Flash is a c plugin, I thought, so is unaffected by this. We did, however, document that the ABI change would break stuff when we froze interfaces. For 1.4, if egcs works, that'd be good, but it was segfaulting for multiple people.
> Does java still segfault if you grab /lib/libgcc_s.so* from RH9, and stick it in > /lib on your RH7 box? > I agre that requireing users to copy libgcc over isn't a solution, but if that > fixes it then it shows what the problem is... Please try it, just for diagnostic > purposes. Here is what I did. On the RH 7.3 machine, I again ran the gcc 3.2.3 build Mozilla 1.4 test build, using Sun's 1.4.2 beta 2 plugin. I crashed again, so I'm sure I can reproduce the problem. Next I tried your suggestion and copied /lib/libgcc_* from RH9 to the RH7.3 test system and repeated my test. I still crash. Note, I don't think the crash is caused by missing system libraries. It's simply caused by the fact that Java 1.4.2 beta is not stable.
Flash is not just a C plugin anymore. They've got XPCOM hooks for Javascript. Has anyone tried building under RH6? Did egcs come with RH6? Also, be sure you symlink the Java plugin instead of copying.
> Has anyone tried building under RH6? Did egcs come with RH6? Yes, according to packages on a RedHat download mirror, egcs 1.1.2 was the standard system compiler for RedHat 6.2. > Also, be sure you symlink the Java plugin instead of copying. That's what I did, I created a symlink.
1.4 branch builds are built with gcc 3.2.3, trunk builds are next. new requirement is glibc 2.2.4 or higher.
I'm assuming the talk here applies to mozilla. What about Mozilla Firebird? Can I request please that milestone releases at the very minimum be built with gcc 3.2.3 as certain plugins don't work? I filed a bug for firebird and thunderbird but it was marked as a duplicate of this one. However, I have not seen any activity on here relating to those packages.
compilers updated for trunk and branch release machines.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified! trunk and branch.
Keywords: fixed1.4, verified1.4
.
Status: RESOLVED → VERIFIED
Keywords: fixed1.4
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.