1181568 - Unable to build Firefox using gcc 5.1.1/glibc 2.21 with --enable-stdcxx-compat

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Bill Gianopoulos [:WG9s]]

I can no longer build Firefox using gcc 5.1.1 after the patch for bug 1179805 landed.

Comment 1

[Bill Gianopoulos [:WG9s]]

I get this error in my 64 bit build:

TEST-UNEXPECTED-FAIL | check_stdcxx | We do not want these libc symbols to be used:
  memcpy@GLIBC_2.14
/home/wag/mozilla/mozilla2/config/rules.mk:739: recipe for target 'TestArrayUtils' failed

and this in my 32-bit build
TEST-UNEXPECTED-FAIL | check_stdcxx | We do not want these libc symbols to be used:
  clock_gettime@GLIBC_2.17
  clock_getres@GLIBC_2.17
/home/wag/mozilla/mozilla2/config/rules.mk:739: recipe for target 'ShowSSEConfig' failed

Comment 2

[Bill Gianopoulos [:WG9s]]

My glibc version is 2.21-5.

Comment 3

[Mike Hommey [:glandium]]

Don't build with --enable-stdcxx-compat.

Comment 4

[Bill Gianopoulos [:WG9s]]

(In reply to Mike Hommey [:glandium] from comment #3)
> Don't build with --enable-stdcxx-compat.

Well, if I do not, doesn't that mean other with older libraries won't be able to run my builds?  The whole point of my builds is that they are for everyone and publicly posted.

Comment 5

[Bill Gianopoulos [:WG9s]]

But I do have a workaround now for my builds so have lowered the severity.

Comment 6

[Bill Gianopoulos [:WG9s]]

This is a valid complaint.  I am using the latest fedora stable release build tools.

Comment 7

[Mike Hommey [:glandium]]

Then don't expect people on older systems to be able to run your builds. --enable-stdcxx-compat is only a small part of the problem, and the unwanted libc symbols message highlights that. You just didn't know, before. If you want people on older systems to be able to run your builds, build on an older system. Or take the necessary steps that make the build on your system run on an older system. By linking an older glibc, for example.

Comment 8

[Bill Gianopoulos [:WG9s]]

I could buy your argument if you made a separate --enable-glibc-check option that I could turn off.

Comment 9

[Bill Gianopoulos [:WG9s]]

YOU can keep resolving this and i can keep reopening ad infinitem, but that is getting us nowhere.

Comment 10

[Bill Gianopoulos [:WG9s]]

This will become an issue for official builds once we update glibc and gcc so would be better to solve it now than have it block being able to use the build tools that are supported upstream.

Comment 11

[Mike Hommey [:glandium]]

(In reply to Bill Gianopoulos [:WG9s] from comment #10)
> This will become an issue for official builds once we update glibc and gcc

No it won't because that was explicitly done to detect problems when updating the build environment on automation. And what we'll do on automation is to ship a glibc along with gcc through tooltool.

(In reply to Bill Gianopoulos [:WG9s] from comment #8)
> I could buy your argument if you made a separate --enable-glibc-check option
> that I could turn off.

And when we possibly add a check for glib symbols, add --enable-glib-check? and for gtk --enable-gtk-check? That's unreasonable. In fact, I'm just tempted to rename --enable-stdcxx-compat to --enable-binary-compat. Or even to remove the configure flag and use an environment variable. The fact that it kind of somehow worked for you is not a reason to add complexity to keep your partial binary compatibility working.

Comment 12

[Bill Gianopoulos [:WG9s]]

Look I can get that you think me marking your check-in as a regressor is invalid, but there is an issue here that at some point will have to be fixed.  Official builds will be done using this version of gcc and glibc and with stdcxx-compat enabled.  At some point this will have to be fixed.  You can defer it or give it low priority, but WONTRFIX is an INVLID resulution.

Comment 13

[Bill Gianopoulos [:WG9s]]

Just wait till the android sdk is updated to use GCC 5 and see what happens to android builds.

Comment 14

[Mike Hommey [:glandium]]

Nothing will happen on android because android builds don't use glibc. And nothing will happen on other builds because the build environment will still be using the right glibc. Again, bug 1179805 is *explicitly* for automation.

Comment 15

[Bill Gianopoulos [:WG9s]]

Well, if that fix is *explicilty* for automation, then please don't do the check for my builds.

Comment 16

[Mike Hommey [:glandium]]

Now, if you're interested in knowing what will *expectedly* break with bug 1179805 is the switch of build environment from centos 6 to ubuntu (can't find the corresponding bug), and that's covered by bug 1179818.

(In reply to Bill Gianopoulos [:WG9s] from comment #15)
> Well, if that fix is *explicilty* for automation, then please don't do the
> check for my builds.

--enable-stdcxx-compat is largely for automation. I'm sorry that you were relying on it, but you shouldn't have. If you do want to rely on it, use the same environment as automation. We're not going to make the setup for automation work on random build environments.

Comment 17

[Bill Gianopoulos [:WG9s]]

Besides the lame idea that we need to be compatible with versions of glibc from 2010 is really lame.

Comment 18

[Mike Hommey [:glandium]]

And we are compatible with versions of libstdc++, glib and gtk+ from 2008.

Comment 19

[Bill Gianopoulos [:WG9s]]

Well kind of my whole issue why do we need to make sure we run on poeples linux systems they have not updated in over 7 years?

Comment 20

[Mike Hommey [:glandium]]

We're also compatible with versions of Windows from 2004 and versions of Mac OSX from 2009.

Comment 21

[Bill Gianopoulos [:WG9s]]

Anyway I will just add a patch to my build to change the maximum required version of glibc form 2.7 to 2.17 I guess.  I can do that.

Comment 22

[Mike Hommey [:glandium]]

And you'll be grateful when it tells you that your builds require 2.22 after you upgrade your build environment.

Comment 23

[Bill Gianopoulos [:WG9s]]

Yes but I am still able to by enabling stdcxx-compat able to provide a level of backward compatibility and now that i understand more how it works can document on my build page what version of glibc is required to run my builds.  SO, although you fought me on this you taught me alot.  SO thank you for that.

Comment 24

[Bill Gianopoulos [:WG9s]]

(In reply to Mike Hommey [:glandium] from comment #18)
> And we are compatible with versions of libstdc++, glib and gtk+ from 2008.

Not sure about that! minimum required glibc seems to be 2.7 which as near as I can determine came out in 2010.

Comment 25

[Mike Hommey [:glandium]]

My point is, when you upgrade to next fedora version, you might introduce a dependency on the glibc it contains (depending on what new symbols the glibc introduces), which will be newer than 2.17.

Comment 26

[Bill Gianopoulos [:WG9s]]

(In reply to Mike Hommey [:glandium] from comment #25)
> My point is, when you upgrade to next fedora version, you might introduce a
> dependency on the glibc it contains (depending on what new symbols the glibc
> introduces), which will be newer than 2.17.

I know that, but now i understand and can document on my builds or test on my test system before i upgrade my build system etc.  So thank you for your help in showing me how this all works.  You may have thought I was being sarcastic when I said that the first time, but really this is a good thing.