Last Comment Bug 643690 - Get rid of dependencies on libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)
: Get rid of dependencies on libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All Linux
: -- normal (vote)
: mozilla6
Assigned To: Mike Hommey [:glandium]
:
Mentors:
http://glandium.org/blog/?p=1901
Depends on: 650467 650480 650503 654080 655216
Blocks: gcc4.5 621704
  Show dependency treegraph
 
Reported: 2011-03-22 03:01 PDT by Mike Hommey [:glandium]
Modified: 2011-05-06 01:02 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
?


Attachments
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1) (11.64 KB, patch)
2011-03-23 04:33 PDT, Mike Hommey [:glandium]
ted: review+
Details | Diff | Splinter Review
part 2 - Check that resulting binaries don't require GLIBCXX_3.4.9 or more (7.11 KB, patch)
2011-03-23 04:33 PDT, Mike Hommey [:glandium]
ted: review+
Details | Diff | Splinter Review
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1) (11.34 KB, patch)
2011-04-14 09:10 PDT, Mike Hommey [:glandium]
taras.mozilla: review+
Details | Diff | Splinter Review
part 2 - Check that resulting binaries don't require GLIBCXX_3.4.9 or more (7.12 KB, patch)
2011-04-14 09:11 PDT, Mike Hommey [:glandium]
mh+mozilla: review+
Details | Diff | Splinter Review

Description Mike Hommey [:glandium] 2011-03-22 03:01:49 PDT
More importantly, get rid of dependencies on libstdc++ symbol versions >= GLIBCXX_3.4.14 (gcc >= 4.5) when building against gcc 4.5.
Comment 1 Mike Hommey [:glandium] 2011-03-23 04:33:21 PDT
Created attachment 521147 [details] [diff] [review]
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)
Comment 2 Mike Hommey [:glandium] 2011-03-23 04:33:41 PDT
Created attachment 521148 [details] [diff] [review]
part 2 - Check that resulting binaries don't require GLIBCXX_3.4.9 or more
Comment 3 Mike Hommey [:glandium] 2011-03-23 04:35:49 PDT
Please note that I need to figure out if the license boiler plate is okay in part 1.
Comment 4 Ted Mielczarek [:ted.mielczarek] 2011-03-25 05:27:49 PDT
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 5 Ted Mielczarek [:ted.mielczarek] 2011-03-25 05:31:20 PDT
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.
Comment 6 Mike Hommey [:glandium] 2011-03-25 11:20:18 PDT
(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.
Comment 7 Mike Hommey [:glandium] 2011-04-14 09:10:04 PDT
Created attachment 526012 [details] [diff] [review]
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)

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.
Comment 8 Mike Hommey [:glandium] 2011-04-14 09:11:36 PDT
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)
Comment 9 Mike Hommey [:glandium] 2011-04-14 09:11:51 PDT
(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 10 (dormant account) 2011-04-14 09:17:49 PDT
Comment on attachment 526012 [details] [diff] [review]
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)

Looks ok
Comment 12 Mike Hommey [:glandium] 2011-04-15 04:18:05 PDT
See bug 621704. Do we want this on aurora and/or macaw/macaw+1 ?
Comment 13 JP Rosevear [:jpr] 2011-04-15 12:28:44 PDT
Not worth even minimal risk for aurora, there is no compelling reason to take it.
Comment 14 Matt Phelps 2011-04-15 12:33:43 PDT
Please reconsider getting this into the next release. There are LOTS of folks running RHEL/CentOS 5 that will need Firefox 4.x
Comment 15 Frederic Bezies 2011-04-16 00:21:38 PDT
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
Comment 16 Mike Hommey [:glandium] 2011-04-16 01:00:50 PDT
(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
Comment 17 Mike Hommey [:glandium] 2011-04-16 03:21:14 PDT
(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.
Comment 18 JP Rosevear [:jpr] 2011-04-25 11:51:11 PDT
(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.

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