Closed
Bug 1181568
Opened 9 years ago
Closed 9 years ago
Unable to build Firefox using gcc 5.1.1/glibc 2.21 with --enable-stdcxx-compat
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: wgianopoulos, Unassigned)
References
Details
(Keywords: regression)
I can no longer build Firefox using gcc 5.1.1 after the patch for bug 1179805 landed.
Reporter | ||
Comment 1•9 years ago
|
||
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
Reporter | ||
Comment 2•9 years ago
|
||
My glibc version is 2.21-5.
Reporter | ||
Updated•9 years ago
|
Summary: Unable to build Firefox using gcc 5.1.1 → Unable to build Firefox using gcc 5.1.1 - glibc 2.21
Reporter | ||
Updated•9 years ago
|
Version: 28 Branch → Trunk
Comment 3•9 years ago
|
||
Don't build with --enable-stdcxx-compat.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 4•9 years ago
|
||
(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.
Reporter | ||
Updated•9 years ago
|
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 5•9 years ago
|
||
But I do have a workaround now for my builds so have lowered the severity.
Severity: blocker → major
Reporter | ||
Updated•9 years ago
|
Summary: Unable to build Firefox using gcc 5.1.1 - glibc 2.21 → Unable to build Firefox using gcc 5.1.1 - glibc 2.21 with --enable-stdcxx-compat
Reporter | ||
Comment 6•9 years ago
|
||
This is a valid complaint. I am using the latest fedora stable release build tools.
Reporter | ||
Updated•9 years ago
|
Summary: Unable to build Firefox using gcc 5.1.1 - glibc 2.21 with --enable-stdcxx-compat → Unable to build Firefox using gcc 5.1.1/glibc 2.21 with --enable-stdcxx-compat
Comment 7•9 years ago
|
||
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.
Updated•9 years ago
|
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 8•9 years ago
|
||
I could buy your argument if you made a separate --enable-glibc-check option that I could turn off.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 9•9 years ago
|
||
YOU can keep resolving this and i can keep reopening ad infinitem, but that is getting us nowhere.
Reporter | ||
Comment 10•9 years ago
|
||
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•9 years ago
|
||
(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.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → INVALID
Updated•9 years ago
|
Resolution: INVALID → WONTFIX
Reporter | ||
Comment 12•9 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reporter | ||
Comment 13•9 years ago
|
||
Just wait till the android sdk is updated to use GCC 5 and see what happens to android builds.
Comment 14•9 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 15•9 years ago
|
||
Well, if that fix is *explicilty* for automation, then please don't do the check for my builds.
Comment 16•9 years ago
|
||
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.
Reporter | ||
Comment 17•9 years ago
|
||
Besides the lame idea that we need to be compatible with versions of glibc from 2010 is really lame.
Comment 18•9 years ago
|
||
And we are compatible with versions of libstdc++, glib and gtk+ from 2008.
Reporter | ||
Comment 19•9 years ago
|
||
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•9 years ago
|
||
We're also compatible with versions of Windows from 2004 and versions of Mac OSX from 2009.
Reporter | ||
Comment 21•9 years ago
|
||
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•9 years ago
|
||
And you'll be grateful when it tells you that your builds require 2.22 after you upgrade your build environment.
Reporter | ||
Comment 23•9 years ago
|
||
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.
Reporter | ||
Comment 24•9 years ago
|
||
(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•9 years ago
|
||
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.
Reporter | ||
Comment 26•9 years ago
|
||
(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.
Assignee | ||
Updated•6 years ago
|
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•