More importantly, get rid of dependencies on libstdc++ symbol versions >= GLIBCXX_3.4.14 (gcc >= 4.5) when building against gcc 4.5.

Please note that I need to figure out if the license boiler plate is okay in part 1.

Comment on attachment 521147 [details] [diff] [review] part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1) ># HG changeset patch >diff --git a/configure.in b/configure.in >--- a/configure.in >+++ b/configure.in > dnl ======================================================== >+dnl = libstdc++ hacks >+dnl ======================================================== >+ >+STDCXX_COMPAT=stdc++compat.cpp >+MOZ_ARG_DISABLE_BOOL(stdc++compat, >+[ --disable-stdc++compat Disable libstdc++ compatibility], >+ STDCXX_COMPAT=) Do we really need a configure arg for this? Are you planning on using it, or is this just in case this breaks someone's build config? The rest of the build bits look fine, but the C++ bits make my head hurt. Can you get a C++ guru to give that a once-over?

Comment on attachment 521148 [details] [diff] [review] part 2 - Check that resulting binaries don't require GLIBCXX_3.4.9 or more >diff --git a/config/config.mk b/config/config.mk >--- a/config/config.mk >+++ b/config/config.mk >@@ -841,8 +841,12 @@ OPTIMIZE_JARS_CMD = $(PYTHON) $(call cor > EXPAND_LIBS = $(PYTHON) -I$(DEPTH)/config $(topsrcdir)/config/expandlibs.py > EXPAND_LIBS_EXEC = $(PYTHON) $(topsrcdir)/config/pythonpath.py -I$(DEPTH)/config $(topsrcdir)/config/expandlibs_exec.py > EXPAND_LIBS_GEN = $(PYTHON) $(topsrcdir)/config/pythonpath.py -I$(DEPTH)/config $(topsrcdir)/config/expandlibs_gen.py > EXPAND_AR = $(EXPAND_LIBS_EXEC) --extract -- $(AR) > EXPAND_CC = $(EXPAND_LIBS_EXEC) --uselist -- $(CC) > EXPAND_CCC = $(EXPAND_LIBS_EXEC) --uselist -- $(CCC) > EXPAND_LD = $(EXPAND_LIBS_EXEC) --uselist -- $(LD) > EXPAND_MKSHLIB = $(EXPAND_LIBS_EXEC) --uselist -- $(MKSHLIB) >+ >+ifdef STDCXX_COMPAT >+CHECK_STDCXX = objdump -p $(1) | grep -e 'GLIBCXX_3\.4\.\(9\|[1-9][0-9]\)' && echo "We don't want these libstdc++ symbol versions to be used" && exit 1 || exit 0 >+endif Stick an "Error: " at the start of that echo so that it shows up in tinderbox logs.

(In reply to comment #4) > >+STDCXX_COMPAT=stdc++compat.cpp > >+MOZ_ARG_DISABLE_BOOL(stdc++compat, > >+[ --disable-stdc++compat Disable libstdc++ compatibility], > >+ STDCXX_COMPAT=) > > Do we really need a configure arg for this? Are you planning on using it, or is > this just in case this breaks someone's build config? Both. With my distro hat on, since I had package dependencies, I don't care about libstdc++ backwards compatibility.

So, only a few changes since the previous version: - option change in configure, as it turns out autoconf doesn't like options containing a +. - ctype<char>::_M_widen_init() is now doing nothing, which simplified the copyright issues further. A little more on the latter. To avoid any copyright issues, I was going to drive a clean-room implementation of that function. While doing a write-up of what it does, I actually figured the following (omitting a few details) - the std::ctype<char> class defines 2 virtual do_widen functions: virtual char_type do_widen(char) const virtual const char* do_widen(const char* __lo, const char* __hi, char_type* __dest) const - except if we have a derived class override these functions (and we don't), the _M_widen_init function only fills a char array (_M_widen) with {0, 1, 2, 3..., 254, 255} and sets _M_widen_ok to 1. That _M_widen array is some kind of cache of the do_widen(char) return values for each character. - There are only two functions calling _M_widen_init: char_type widen(char __c) const const char* widen(const char* __lo, const char* __hi, char_type* __to) const In both functions, after _M_widen_init is called, they call the corresponding do_widen function and don't rely on neither _M_widen nor _M_widen_ok. Only on the next call to these functions _M_widen_ok and _M_widen may be used. - In both functions, when _M_widen_ok is 0, we go through the _M_widen_init function, then do_widen. So all in all, we actually don't need _M_widen_init to do anything at all, and just having a dummy function makes things work. Slightly slower, but work. And it looks like there's nothing in firefox release binaries that actually calls _M_widen_init, only build tools such as elfhack. And a function only returning is small enough that it's not worth making that conditional.

Addressed ted's comment and refreshed context (there was a change on m-c in config/config.mk)

(In reply to comment #8) > Created attachment 526013 [details] [diff] [review] > part 2 - Check that resulting binaries don't require GLIBCXX_3.4.9 or more > > Addressed ted's comment and refreshed context (there was a change on m-c in > config/config.mk) config/rules.mk, that was.

Comment on attachment 526012 [details] [diff] [review] part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1) Looks ok

http://hg.mozilla.org/mozilla-central/rev/3a38a70b0e12 http://hg.mozilla.org/mozilla-central/rev/2aa8ce6b37e0

See bug 621704. Do we want this on aurora and/or macaw/macaw+1 ?

Not worth even minimal risk for aurora, there is no compelling reason to take it.

Please reconsider getting this into the next release. There are LOTS of folks running RHEL/CentOS 5 that will need Firefox 4.x

Erh, sorry to spam this bug, but I cannot get mozilla nightly to get build with gcc 4.6 on archlinux. Got this error with nsRDFResource.cpp : nsRDFResource.cpp 0x0297f865 0x00 20 GLIBCXX_3.4.15 Error: We don't want these libstdc++ symbol versions to be used make[5]: *** [libxul.so] Error 1 make[5]: *** Removing file « libxul.so » make[4]: *** [libs_tier_platform] Error 2 make[3]: *** [tier_platform] Error 2 make[2]: *** [default] Error 2 make[1]: *** [realbuild] Error 2 make: *** [build] Error 2

(In reply to comment #15) > Erh, sorry to spam this bug, but I cannot get mozilla nightly to get build with > gcc 4.6 on archlinux. > > Got this error with nsRDFResource.cpp : > > nsRDFResource.cpp > 0x0297f865 0x00 20 GLIBCXX_3.4.15 > Error: We don't want these libstdc++ symbol versions to be used > make[5]: *** [libxul.so] Error 1 > make[5]: *** Removing file « libxul.so » > make[4]: *** [libs_tier_platform] Error 2 > make[3]: *** [tier_platform] Error 2 > make[2]: *** [default] Error 2 > make[1]: *** [realbuild] Error 2 > make: *** [build] Error 2 Please configure with the --disable-stdcxx-compat flag, build, run the following command (replacing $objdir with whatever your object dir is): objdump -T $objdir/dist/bin/libxul.so | grep GLIBCXX_3.4.15 And file a new bug for a failure to build with gcc 4.6 with the resulting data. Thanks

(In reply to comment #16) > Please configure with the --disable-stdcxx-compat flag, build, run the > following command (replacing $objdir with whatever your object dir is): > objdump -T $objdir/dist/bin/libxul.so | grep GLIBCXX_3.4.15 > And file a new bug for a failure to build with gcc 4.6 with the resulting data. I was actually able to build with gcc 4.6 and find a fix. Filed bug 650480.

(In reply to comment #14) > Please reconsider getting this into the next release. There are LOTS of folks > running RHEL/CentOS 5 that will need Firefox 4.x The 6.0 release train is only 6 weeks behind, and this is fixed for mozilla-central, so help is coming.