Closed
Bug 643690
Opened 14 years ago
Closed 14 years ago
Get rid of dependencies on libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox5-, status2.0 ?)
RESOLVED
FIXED
mozilla6
People
(Reporter: glandium, Assigned: glandium)
References
()
Details
Attachments
(2 files, 2 obsolete files)
11.34 KB,
patch
|
taras.mozilla
:
review+
|
Details | Diff | Splinter Review |
7.12 KB,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
More importantly, get rid of dependencies on libstdc++ symbol versions >= GLIBCXX_3.4.14 (gcc >= 4.5) when building against gcc 4.5.
Assignee | ||
Comment 1•14 years ago
|
||
Assignee: nobody → mh+mozilla
Attachment #521147 -
Flags: review?(ted.mielczarek)
Assignee | ||
Comment 2•14 years ago
|
||
Attachment #521148 -
Flags: review?(ted.mielczarek)
Assignee | ||
Updated•14 years ago
|
Assignee | ||
Comment 3•14 years ago
|
||
Please note that I need to figure out if the license boiler plate is okay in part 1.
Comment 4•14 years ago
|
||
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?
Attachment #521147 -
Flags: review?(ted.mielczarek) → review+
Comment 5•14 years ago
|
||
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.
Attachment #521148 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 6•14 years ago
|
||
(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.
Assignee | ||
Comment 7•14 years ago
|
||
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.
Attachment #521147 -
Attachment is obsolete: true
Attachment #526012 -
Flags: review?(tglek)
Assignee | ||
Comment 8•14 years ago
|
||
Addressed ted's comment and refreshed context (there was a change on m-c in config/config.mk)
Attachment #521148 -
Attachment is obsolete: true
Attachment #526013 -
Flags: review+
Assignee | ||
Comment 9•14 years ago
|
||
(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•14 years ago
|
||
Comment on attachment 526012 [details] [diff] [review]
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)
Looks ok
Attachment #526012 -
Flags: review?(tglek) → review+
Assignee | ||
Comment 11•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/3a38a70b0e12
http://hg.mozilla.org/mozilla-central/rev/2aa8ce6b37e0
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Assignee | ||
Comment 12•14 years ago
|
||
See bug 621704. Do we want this on aurora and/or macaw/macaw+1 ?
tracking-firefox5:
--- → ?
Comment 13•14 years ago
|
||
Not worth even minimal risk for aurora, there is no compelling reason to take it.
Comment 14•14 years ago
|
||
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•14 years ago
|
||
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
Assignee | ||
Comment 16•14 years ago
|
||
(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
Assignee | ||
Comment 17•14 years ago
|
||
(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•14 years ago
|
||
(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.
Updated•7 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•