Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED in mozilla6

Status

()

Core
Build Config
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: glandium, Assigned: glandium)

Tracking

Trunk
mozilla6
All
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox5-, status2.0 ?)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Assignee)

Description

6 years ago
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

6 years ago
Created attachment 521147 [details] [diff] [review]
part 1 - Avoid requiring libstdc++ symbol versions > GLIBCXX_3.4.8 (gcc > 4.1)
Assignee: nobody → mh+mozilla
Attachment #521147 - Flags: review?(ted.mielczarek)
(Assignee)

Comment 2

6 years ago
Created attachment 521148 [details] [diff] [review]
part 2 - Check that resulting binaries don't require GLIBCXX_3.4.9 or more
Attachment #521148 - Flags: review?(ted.mielczarek)
(Assignee)

Updated

6 years ago
(Assignee)

Comment 3

6 years ago
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+
(Assignee)

Comment 6

6 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

6 years ago
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.
Attachment #521147 - Attachment is obsolete: true
Attachment #526012 - Flags: review?(tglek)
(Assignee)

Comment 8

6 years ago
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)
Attachment #521148 - Attachment is obsolete: true
Attachment #526013 - Flags: review+
(Assignee)

Comment 9

6 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

6 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

6 years ago
http://hg.mozilla.org/mozilla-central/rev/3a38a70b0e12
http://hg.mozilla.org/mozilla-central/rev/2aa8ce6b37e0
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
(Assignee)

Comment 12

6 years ago
See bug 621704. Do we want this on aurora and/or macaw/macaw+1 ?
status2.0: --- → ?
tracking-firefox5: --- → ?

Comment 13

6 years ago
Not worth even minimal risk for aurora, there is no compelling reason to take it.
tracking-firefox5: ? → -

Comment 14

6 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

6 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)

Updated

6 years ago
Depends on: 650467
(Assignee)

Comment 16

6 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)

Updated

6 years ago
Depends on: 650480
(Assignee)

Comment 17

6 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.
(Assignee)

Updated

6 years ago
Depends on: 650503
Blocks: 621704

Comment 18

6 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.
(Assignee)

Updated

6 years ago
Depends on: 654080
(Assignee)

Updated

6 years ago
Depends on: 655216
You need to log in before you can comment on or make changes to this bug.