936790 - (gcc 4.5) Build error: "We don't want these libstdc++ symbols to be used" when building with --enable-stdcxx-compat and WebRTC

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Bill Gianopoulos [:WG9s]]

Error is:

TEST-UNEXPECTED-FAIL | | We don't want these libstdc++ symbols to be used:
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.14 _ZNSt15_List_node_base10_M_reverseEv
make[5]: *** [libxul.so] Error 1
make[5]: *** Deleting file `libxul.so'
make[5]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj/toolkit/library'
make[4]: *** [toolkit/library/libs] Error 2
make[4]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj'
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory `/home/wag/mozilla/mozilla2'
make: *** [build] Error 2

I will add more information when I determine the regressor.

Comment 1

[Bill Gianopoulos [:WG9s]]

It appears this is intentional.  The latest version of Webrtc provided by bug 932112 seems to require GCC 4.6 or later.  It would be nice if this were checked for in configure instead of failing at the final link stage of the build.

I am trying a clobber build with --disable-webrtc to make sure this actually avoids the issue.

Comment 2

[Bill Gianopoulos [:WG9s]]

I updated https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Linux_Prerequisites with that info.

Comment 3

[Bill Gianopoulos [:WG9s]]

Building with --disable-webrtc is sufficient to avoid this issue.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Glandium: any easy way to avoid this for 4.5 (variant on the patch you did?)  

Sorry about the 4.5 issue; no easy to to notice that ahead of time.  I'll try to ping you on the next import so you can try the patch ahead of time.

Comment 5

[Mike Hommey [:glandium]]

https://hg.mozilla.org/mozilla-central/rev/03701a9c0f82 should have taken care of this. And if that was really a problem that would fail on tbpl too. What tree have you been using?

Comment 6

[Mike Hommey [:glandium]]

(In reply to Bill Gianopoulos [:WG9s] from comment #2)
> I updated
> https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/
> Linux_Prerequisites with that info.

You shouldn't have. Also, the only reason you're hitting this is because you're building with --enable-stdcxx-compat. Which is not the default for local builds.

Comment 7

[Bill Gianopoulos [:WG9s]]

(In reply to Mike Hommey [:glandium] from comment #6)

> You shouldn't have. Also, the only reason you're hitting this is because
> you're building with --enable-stdcxx-compat. Which is not the default for
> local builds.

I realize that I would not get this particualr error if I did not specify --enable-stdcxx-compat.  However, would the webrtc code that calls these functions actually work correctly on such a configuration?

Comment 8

[Mike Hommey [:glandium]]

(In reply to Bill Gianopoulos [:WG9s] from comment #7)
> I realize that I would not get this particualr error if I did not specify
> --enable-stdcxx-compat.  However, would the webrtc code that calls these
> functions actually work correctly on such a configuration?

Yes, the only thing is that if you then copy your build on a system with an older libstdc++, it won't work. That's all.

Comment 9

[Bill Gianopoulos [:WG9s]]

(In reply to Mike Hommey [:glandium] from comment #8)
> (In reply to Bill Gianopoulos [:WG9s] from comment #7)
> > I realize that I would not get this particualr error if I did not specify
> > --enable-stdcxx-compat.  However, would the webrtc code that calls these
> > functions actually work correctly on such a configuration?
> 
> Yes, the only thing is that if you then copy your build on a system with an
> older libstdc++, it won't work. That's all.

Well, as it turns out, building with webrtc enabled and stdcxx-comat disabled results in this error.

/home/wag/mozilla/mozilla2/media/webrtc/trunk/testing/gtest/include/gtest/gtest.h:1532:136: error: ISO C++ forbids comparison between pointer and integer
make[5]: *** [rlogringbuffer_unittest.o] Error 1
make[5]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj/media/mtransport/test'
make[4]: *** [media/mtransport/test/compile] Error 2
make[4]: *** Waiting for unfinished jobs....
make[5]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj/webapprt/gtk2'
make[4]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj'
make[3]: *** [compile] Error 2
make[3]: Leaving directory `/home/wag/mozilla/mozilla2/fx-obj'

Comment 10

[Mike Hommey [:glandium]]

which is unrelated and would need its own bug.

Comment 11

[Bill Gianopoulos [:WG9s]]

But still would seem an advisory not to use gcc 4.5 to build with webrtc enabled is warranted.

Comment 12

[Mike Hommey [:glandium]]

(In reply to Bill Gianopoulos [:WG9s] from comment #11)
> But still would seem an advisory not to use gcc 4.5 to build with webrtc
> enabled is warranted.

No, it would if it stayed that way long enough.

Comment 13

[Bill Gianopoulos [:WG9s]]

(In reply to Mike Hommey [:glandium] from comment #10)
> which is unrelated and would need its own bug.

I filed Bug 938092.

Comment 14

[Justin Wood (:Callek)]

(In reply to Mike Hommey [:glandium] from comment #6)
> (In reply to Bill Gianopoulos [:WG9s] from comment #2)
> > I updated
> > https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/
> > Linux_Prerequisites with that info.
> 
> You shouldn't have. Also, the only reason you're hitting this is because
> you're building with --enable-stdcxx-compat. Which is not the default for
> local builds.

I should note, this is the configuration used by SeaMonkey as well, and this bug is what is causing our aurora to be busted on linux atm.

We will likely disable WebRTC in the meantime, but would be nice if there was a workaround.

Comment 15

[Frank Wein [:mcsmurf]]

I can reproduce this in some way locally with gcc 4.5, so quite likely a version specific problem (cannot reproduce with gcc 4.8.1), my build fails earlier though:
11:54.53 libnptest.so
11:54.60 TEST-UNEXPECTED-FAIL | | We do not want these libstdc++ symbols to be used:
11:54.61 0000000000000000      DF *UND* 0000000000000000  GLIBCXX_3.4.14 _ZNSt15_List_node_base9_M_unhookEv
11:54.61 0000000000000000      DF *UND* 0000000000000000  GLIBCXX_3.4.14 _ZNSt15_List_node_base7_M_hookEPS_
11:54.62 0000000000000000      DF *UND* 0000000000000000  GLIBCXX_3.4.14 _ZNSt15_List_node_base11_M_transferEPS_S0_

(not sure why). Related vars from mozilla/config.status:
    (''' MOZ_LIBSTDCXX_TARGET_VERSION ''', r''' 197651 '''),
    (''' MOZ_LIBSTDCXX_HOST_VERSION ''', r''' 197651 '''),

Comment 16

[Frank Wein [:mcsmurf]]

Maybe I should file a second bug for this though, just tell me.

Comment 17

[Frank Wein [:mcsmurf]]

Maybe the problem is that the _M_* symbols are now inside the detail namespace since gcc and glibc 4.6? "ldd libstdc++compat.a" gives:
000000000000006e T _ZNSt8__detail15_List_node_base10_M_reverseEv
0000000000000062 T _ZNSt8__detail15_List_node_base11_M_transferEPS0_S1_
0000000000000068 T _ZNSt8__detail15_List_node_base4swapERS0_S1_
0000000000000056 T _ZNSt8__detail15_List_node_base7_M_hookEPS0_
000000000000005c T _ZNSt8__detail15_List_node_base9_M_unhookEv

So the stdc++compat.cpp file is doing the wrong thing when the gcc compiler version is older than/does not match the libstdc++.so file used by -lstdc++? I checked: On my system libstdc++.so in the /usr/lib/ gcc 4.5.3 folder just symlinks to /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18 which is the gcc 4.8 version (installed from official Ubuntu package system). Anyway, I probably cannot fix this, I don't know enough about this :)

Comment 18

[Frank Wein [:mcsmurf]]

So, to get back to the original problem from Comment 0 and Comment 14 (ignore Comment 15 to 17 for now): This Linux build box uses libstdc++ 3.4.14 looks like: "-DMOZ_LIBSTDCXX_VERSION=197646". The _M_reverse deceleration in stdc++compat.cpp is inside the 3.4.15 block though:
#if MOZ_LIBSTDCXX_VERSION >= GLIBCXX_VERSION(3, 4, 15)
[...]
void _M_reverse() throw();
#endif

So the _M_reverse (and also the reverse deceleration?) need to get moved above that ifdef so that it gets included in the 3.4.14 section I think.

Comment 19

[Frank Wein [:mcsmurf]]

Attachment: Patch?

Feel free to redirect the review request to someone else, not sure how busy you are with the existing requests.

So, I think this patch should fix the issue, but I'm not that familiar with this area of code. According to "readelf -Ws  libstdc++.so.6.0.18|awk '{print $8}'" the (relevant) symbols for reverse are:
_ZNSt15_List_node_base7reverseEv@@GLIBCXX_3.4
_ZNSt15_List_node_base10_M_reverseEv@@GLIBCXX_3.4.14
_ZNSt8__detail15_List_node_base10_M_reverseEv@@GLIBCXX_3.4.15

I've tested it on try linux32/64 with mochitest-1 as I was not sure if build-only does a runtime/startup test.

Merry Christmas everyone! :)

Comment 20

[Frank Wein [:mcsmurf]]

Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/d706ebf6e5b1

Comment 21

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/d706ebf6e5b1

Comment 22

[Frank Wein [:mcsmurf]]

Comment on attachment 8351375 [details] [diff] [review]
Patch?

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 932112
User impact if declined: Affects developers only (compile failure with Linux gcc 4.5)
Testing completed (on m-c, etc.): Works fine on mozilla-central
Risk to taking this patch (and alternatives if risky): Almost no risk, this code has already been tested for a while for newer Linux gcc compilers, now this code also gets used for an older version of gcc
String or IDL/UUID changes made by this patch: -

Comment 23

[Frank Wein [:mcsmurf]]

Pushed: https://hg.mozilla.org/releases/mozilla-aurora/rev/c1a8d1aee8e8