| Summary: | >=www-client/firefox-91.0 fails to build on x86 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Morgan Wesström <gentoo-bugzilla> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | berni.lakeroe, bugs.gentoo, ionen, lynx1534 |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | https://bugzilla.mozilla.org/show_bug.cgi?id=1729459 | ||
| See Also: |
https://bugzilla.mozilla.org/show_bug.cgi?id=1729459 https://github.com/gentoo/gentoo/pull/23078 https://bugs.gentoo.org/show_bug.cgi?id=915336 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
Complete build.log build.log.gz emerge.info.log fix for math_private.h build issue on x86 build.log from eeePC 901 /proc/cpuinfo from eeePC 901 emerge --info from eeePC 901 |
||
|
Description
Morgan Wesström
2021-10-08 14:43:59 UTC
Created attachment 743847 [details]
Complete build.log
I could reproduce this exact error on x86 container, but neither of the patches provided fix it for me. Need to dig deeper into it, maybe FreeBSD's previous patches are somehow interacting with that one. Hm, I am hitting this error on a x86_64 machine :/ But I have for most packages ABI_X86="32 64" set. 166:40.70 In file included from /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/e_acos.cpp:44: 166:40.70 /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/math_private.h:34:21: error: conflicting declaration 'typedef __double_t double_t' 166:40.70 34 | typedef __double_t double_t; 166:40.71 | ^~~~~~~~ 166:40.71 In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11/cmath:45, 166:40.71 from /var/tmp/portage/www-client/firefox-93.0/work/firefox_build/instrumented/dist/system_wrappers/cmath:3, 166:40.71 from /var/tmp/portage/www-client/firefox-93.0/work/firefox_build/instrumented/dist/stl_wrappers/cmath:64, 166:40.71 from /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/e_acos.cpp:41: 166:40.71 /usr/include/math.h:156:21: note: previous declaration as 'typedef long double double_t' 166:40.71 156 | typedef long double double_t; 166:40.71 | ^~~~~~~~ Created attachment 744135 [details]
build.log.gz
Created attachment 744138 [details]
emerge.info.log
(In reply to Conrad Kostecki from comment #3) > Hm, I am hitting this error on a x86_64 machine :/ > But I have for most packages ABI_X86="32 64" set. > Wasn't able to reproduce this with your USE flags on ~amd64 container, nor with random USE flags either. I have ABI_X86="64 32" globally set there. Maybe something wrong with your CFLAGS? I was able to build www-client/firefox-92.0 on x86 without any issues, so title of this bug may not be completely correct. However, I did run into the "math_private.h" build issue in www-client/firefox-93.0 and I managed to create a patch that resolves the issue. My patch (attached separately) is a modified version of that provided up stream here: https://bugzilla.mozilla.org/show_bug.cgi?id=1729459#c12 My changes to that up stream patch address the following new issues it introduces: 8 0:48.08 In file included from /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/e_acos.cpp:44: 8 0:48.08 /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/math_private.h:638:8: error: unknown type name '__float_t'; did you mean 'float_t'? 8 0:48.08 rnintf(__float_t x) 8 0:48.08 ^~~~~~~~~ 8 0:48.09 float_t 8 0:48.09 /usr/include/math.h:155:21: note: 'float_t' declared here 8 0:48.09 typedef long double float_t; 8 0:48.09 ^ 8 0:48.09 In file included from /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/e_acos.cpp:44: 8 0:48.10 /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/math_private.h:662:14: error: exponent has no digits 8 0:48.10 return (x + __CONCAT(0x1.8p, LDBL_MANT_DIG) / 2 - 8 0:48.10 ^ 8 0:48.10 /usr/include/sys/cdefs.h:109:23: note: expanded from macro '__CONCAT' 8 0:48.11 #define __CONCAT(x,y) x ## y 8 0:48.11 ^ 8 0:48.11 <scratch space>:283:6: note: expanded from here 8 0:48.11 0x1.8pLDBL_MANT_DIG 8 0:48.12 ^ 8 0:48.12 In file included from /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/e_acos.cpp:44: 8 0:48.12 /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/math_private.h:663:3: error: exponent has no digits 8 0:48.13 __CONCAT(0x1.8p, LDBL_MANT_DIG) / 2); 8 0:48.13 ^ 8 0:48.13 /usr/include/sys/cdefs.h:109:23: note: expanded from macro '__CONCAT' 8 0:48.13 #define __CONCAT(x,y) x ## y 8 0:48.13 ^ 8 0:48.14 <scratch space>:284:6: note: expanded from here 8 0:48.14 0x1.8pLDBL_MANT_DIG 8 0:48.14 ^ 8 0:48.15 3 errors generated. Created attachment 745218 [details, diff] fix for math_private.h build issue on x86 As mentioned previously, this is a modified version of the up stream patch (https://bugzilla.mozilla.org/show_bug.cgi?id=1729459#c12) which addresses the new issues that one introduces. My changes very likely can be improved upon, but they do work. (In reply to acmondor from comment #7) > I was able to build www-client/firefox-92.0 on x86 without any issues, so > title of this bug may not be completely correct. See upstream issue, 91esr and 93+ are affected, >=91 is just to make this simpler (92 has no relevance anymore anyway, while 91esr is due to be added to the tree in time) I've *randomly* been hit by this when trying to stabilize firefox-91.3.0 on x86 container. I did 10 runs earlier today, and these are the flags that were used on *every* failed run: -clang hardened system-av1 system-icu system-libvpx wayland if I compare these to the *both* build.logs available in this bug, "system-av1" & "system-libvpx" are presented in *every* failed, documented build here. Now both libvpx and libdav1d are multilibbed, which may somehow explain conikost's error. What I'm trying to say, it may be libdav1d or libvpx related instead. ^ Okay, that's not it. Just did few runs with "+system-av1 -system-libvpx", "-system-av1 +system-libvpx", "+system-av1 +system-libvpx" and they all succeeded. *sigh* it seems totally random then. This issue affects www-client/firefox-94.0.1 x86 builds in the same way and my previously supplied patch work there was well. See comment in upstream bug report from Debian which dropped your patch in the meanwhile. It addresses x86 but breaks others. Besides that patch doesn't give me 100 % certainty - it keeps failing occassionally even with it, to the same error :I Say if I launch 30 build tests, ~1/3 fails with or without the patch here. (And the interesting part is that 8-9 out of those 10 happen with gcc) (In reply to Thomas Deutschmann from comment #13) > See comment in upstream bug report from Debian which dropped your patch in > the meanwhile. It addresses x86 but breaks others. Of course, we could apply it conditionally, but yeah, it doesn’t seem to always work for juippis anyway. (In reply to Joonas Niilola from comment #14) > Besides that patch doesn't give me 100 % certainty - it keeps failing > occassionally even with it, to the same error :I > > Say if I launch 30 build tests, ~1/3 fails with or without the patch here. > (And the interesting part is that 8-9 out of those 10 happen with gcc) Are the logs for those build failures available for viewing somewhere? (In reply to acmondor from comment #16) > (In reply to Joonas Niilola from comment #14) > > Besides that patch doesn't give me 100 % certainty - it keeps failing > > occassionally even with it, to the same error :I > > > > Say if I launch 30 build tests, ~1/3 fails with or without the patch here. > > (And the interesting part is that 8-9 out of those 10 happen with gcc) > > Are the logs for those build failures available for viewing somewhere? Oh yea, forgot to paste. I uploaded one: https://dev.gentoo.org/~juippis/logs/firefox-91.3.0-20211105-072920.log ---------- * Applying 1.patch ... [ ok ] * User patches applied. ---------- is the https://bug1729459.bmoattachments.org/attachment.cgi?id=9247105 one placed in /etc/portage/patches Joonas, Thanks for the log info. After going through it carefully and comparing to some of my build logs, and digging through various bits of code I'm quite sure the firefox-91.3.0 random build failures are due to the following compiler option:
-march=native
And, that may actually be a clang compile bug (see below).
Here's how I came to that conclusion:
1) The firefox-91.3.0 build error is this:
3:56.16 /usr/lib/llvm/12/bin/i686-pc-linux-gnu-clang++ -std=gnu++17 -o e_acos.o -c ... -march=native ....
13:56.53 In file included from /var/tmp/portage/www-client/firefox-91.3.0/work/firefox-91.3.0/modules/fdlibm/src/e_acos.cpp:44:
13:56.53 /var/tmp/portage/www-client/firefox-91.3.0/work/firefox-91.3.0/modules/fdlibm/src/math_private.h:38:21: error: typedef redefinition with different types ('__double_t' (aka 'long double') vs 'double')
13:56.53 typedef __double_t double_t;
13:56.53 ^
13:56.53 /usr/include/math.h:150:16: note: previous definition is here
13:56.53 typedef double double_t;
13:56.53 ^
13:56.62 1 error generated.
2) The patched math_private.h file includes this code:
33 #ifdef __LP64__
34 typedef double __double_t;
35 #else
36 typedef long double __double_t; <<< this line is used on x86
37 #endif
38 typedef __double_t double_t; <<< compile error generated due to this line
39 typedef float __float_t;
3) The file /usr/include/math.h includes this code:
148 # if __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
149 typedef float float_t;
150 typedef double double_t; <<< this is the previous definition mentioned in the error
151 # elif __GLIBC_FLT_EVAL_METHOD == 1
152 typedef double float_t;
153 typedef double double_t;
154 # elif __GLIBC_FLT_EVAL_METHOD == 2
155 typedef long double float_t;
156 typedef long double double_t; <<< this is what is expected by the patch
157 # elif __GLIBC_FLT_EVAL_METHOD == 32
158 typedef _Float32 float_t;
159 typedef double double_t;
4) __GLIBC_FLT_EVAL_METHOD is from /usr/include/bits/flt-eval-method.h:
23 #ifdef __FLT_EVAL_METHOD__
24 # if __FLT_EVAL_METHOD__ == -1
25 # define __GLIBC_FLT_EVAL_METHOD 2
26 # else
27 # define __GLIBC_FLT_EVAL_METHOD __FLT_EVAL_METHOD__
28 # endif
29 #elif defined __x86_64__
30 # define __GLIBC_FLT_EVAL_METHOD 0
31 #else
32 # define __GLIBC_FLT_EVAL_METHOD 2
33 #endif
5) __FLT_EVAL_METHOD__ comes from the compiler/preprocessor and with clang its value depends
on -march, whereas with gcc it does not:
Here's the output of the clang preprocessor, which is depends on -march:
$ clang-cpp -march=i686 -dM /dev/null | grep __FLT_EVAL_METHOD__
#define __FLT_EVAL_METHOD__ 2
$ clang-cpp -march=native -dM /dev/null | grep __FLT_EVAL_METHOD__
#define __FLT_EVAL_METHOD__ 0
Here's the output of the gcc preprocessor, which does not depend on -march:
$ cpp -dM /dev/null | grep FLT_EVAL_METHOD
#define __FLT_EVAL_METHOD__ 2
$ cpp -march=native -dM /dev/null | grep FLT_EVAL_METHOD
#define __FLT_EVAL_METHOD__ 2
Could this be a clang bug since it's behaviour is different then gcc?
All that shows that the build will fail if clang is used and -march=native. Builds
done with clang and -march=i686 or gcc and any -march setting should work.
For my build I used clang with -march=i686 (set in make.conf).
Is it possible that your builds are inconsistent w.r.t. the setting of -march?
You might be on to something. But first I want to say that I hit that error with both gcc and clang, when using march=native. So this morning I set -march=i686 and launched 20 build tests with the patch linked above. None failed (to that old error, 2 failures were due to bundled libvpx for some reason) Then I took the patch out, kept -march=i686 and it failed to that typedef thing immediately, and repeatedly. So we've learned this problem only appears in the emulated environments (amd64->x86 chroots, containers...) and not on real x86. I also find it weird it only hits me 1/3 of time with -march=native, but 100 % of time with -march=i686. Removing the blocker. Cannot reproduce on real x86 hardware and looks like an issue caused by chroot setup (you need non-x86 march/mtune value to trigger this). *** Bug 829376 has been marked as a duplicate of this bug. *** *** Bug 829376 has been marked as a duplicate of this bug. *** (In reply to Thomas Deutschmann from comment #21) > Removing the blocker. Cannot reproduce on real x86 hardware and looks like > an issue caused by chroot setup (you need non-x86 march/mtune value to > trigger this). How is that consistent with i686 triggering it? Also, that's still obviously a bug in the build system if nothing else. Diffing configure may be useful. There's a simpler patch on the upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1729459#c25 The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7a46f2e91e93ea080197fff32d4c53c2c581e584 commit 7a46f2e91e93ea080197fff32d4c53c2c581e584 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-01-11 20:29:44 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-01-11 20:31:58 +0000 www-client/firefox: add 91.5.0 Closes: https://bugs.gentoo.org/816975 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 99 +++ www-client/firefox/firefox-91.5.0.ebuild | 1235 ++++++++++++++++++++++++++++++ 2 files changed, 1334 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1c03ed06824c778c9cd44087c9f10a16beb1bf39 commit 1c03ed06824c778c9cd44087c9f10a16beb1bf39 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-01-13 06:30:37 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-01-13 06:30:37 +0000 mail-client/thunderbird: update patch set - include a patch to fix build on emulated x86, src/math_private.h:34:21: error: typedef redefinition with different types ('__double_t' (aka 'double') vs 'long double') 20:11.84 typedef __double_t double_t; 20:11.84 ^ 20:11.84 /usr/include/math.h:156:21: note: previous definition is here 20:11.84 typedef long double double_t; 20:11.84 ^ 20:11.93 1 error generated. Bug: https://bugs.gentoo.org/816975 Signed-off-by: Joonas Niilola <juippis@gentoo.org> mail-client/thunderbird/Manifest | 1 + mail-client/thunderbird/thunderbird-91.5.0.ebuild | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) Thank you. I can confirm the problem is solved on =www-client/firefox-91.5.0 although it remains on =www-client/firefox-96.0. For future reference I want to correct the notion that this is an "emulated x86" problem. I get the same compilation failure on native x86, in my case an old eeePC 901. i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux (In reply to Morgan Wesström from comment #28) > i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux > That's indeed a real 32-bit CPU without 64-bit instruction set. I'd very much enjoy a failed build.log from that, if you happen to still have one around, and a snip from /proc/cpuinfo if you will. > although it remains on =www-client/firefox-96.0. > Need to look at 96 at some point, then! Created attachment 762097 [details]
build.log from eeePC 901
Created attachment 762098 [details]
/proc/cpuinfo from eeePC 901
Created attachment 762099 [details]
emerge --info from eeePC 901
(In reply to Joonas Niilola from comment #29) > (In reply to Morgan Wesström from comment #28) > > i686 Intel(R) Atom(TM) CPU N270 @ 1.60GHz GenuineIntel GNU/Linux > > > > That's indeed a real 32-bit CPU without 64-bit instruction set. I'd very > much enjoy a failed build.log from that, if you happen to still have one > around, and a snip from /proc/cpuinfo if you will. > Attached as requested. :) 96.0.2 now holds the patch for x86. |
