Closed Bug 643690 Opened 13 years ago Closed 13 years ago

Get rid of dependencies on libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)

Categories

(Firefox Build System :: General, defect)

All
Linux
defect
Not set
normal

Tracking

(firefox5-, status2.0 ?)

RESOLVED FIXED
mozilla6
Tracking Status
firefox5 - ---
status2.0 --- ?

People

(Reporter: glandium, Assigned: glandium)

References

()

Details

Attachments

(2 files, 2 obsolete files)

More importantly, get rid of dependencies on libstdc++ symbol versions >= GLIBCXX_3.4.14 (gcc >= 4.5) when building against gcc 4.5.
Assignee: nobody → mh+mozilla
Attachment #521147 - Flags: review?(ted.mielczarek)
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?
Attachment #521147 - Flags: review?(ted.mielczarek) → review+
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+
(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.
Attachment #521147 - Attachment is obsolete: true
Attachment #526012 - Flags: review?(tglek)
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+
(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
Attachment #526012 - Flags: review?(tglek) → review+
http://hg.mozilla.org/mozilla-central/rev/3a38a70b0e12
http://hg.mozilla.org/mozilla-central/rev/2aa8ce6b37e0
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
See bug 621704. Do we want this on aurora and/or macaw/macaw+1 ?
status2.0: --- → ?
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
Depends on: 650467
(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
Depends on: 650480
(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.
Depends on: 650503
Blocks: 621704
(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.
Depends on: 654080
Depends on: 655216
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: