Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 816975 - >=www-client/firefox-91.0 fails to build on x86
Summary: >=www-client/firefox-91.0 fails to build on x86
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL: https://bugzilla.mozilla.org/show_bug...
Whiteboard:
Keywords: PullRequest
: 829376 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-10-08 14:43 UTC by Morgan Wesström
Modified: 2022-02-11 11:16 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info.txt,5.57 KB, text/plain)
2021-10-08 14:43 UTC, Morgan Wesström
Details
Complete build.log (build.log.gz,448.33 KB, application/gzip)
2021-10-08 14:47 UTC, Morgan Wesström
Details
build.log.gz (build.log.gz,620.01 KB, application/gzip)
2021-10-09 16:49 UTC, Conrad Kostecki
Details
emerge.info.log (emerge.info.log,6.93 KB, text/plain)
2021-10-09 16:49 UTC, Conrad Kostecki
Details
fix for math_private.h build issue on x86 (firefox-93.0_x86_math_private.patch,2.72 KB, patch)
2021-10-16 20:54 UTC, acmondor
Details | Diff
build.log from eeePC 901 (build.log.gz,474.03 KB, application/gzip)
2022-01-13 16:22 UTC, Morgan Wesström
Details
/proc/cpuinfo from eeePC 901 (cpuinfo.eeepc901,1.48 KB, text/plain)
2022-01-13 16:23 UTC, Morgan Wesström
Details
emerge --info from eeePC 901 (emerge-info.eeepc901,5.78 KB, text/plain)
2022-01-13 16:24 UTC, Morgan Wesström
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Morgan Wesström 2021-10-08 14:43:59 UTC
Created attachment 743844 [details]
emerge --info

=www-client/firefox-93.0 fails to build on x86 with the following error:

111:59.12 In file included from /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/e_acos.cpp:44:
111:59.12 /var/tmp/portage/www-client/firefox-93.0/work/firefox-93.0/modules/fdlibm/src/math_private.h:34:21: error: typedef redefinition with different types ('__double_t' (aka 'double') vs 'long double')
111:59.12 typedef __double_t  double_t;
111:59.12                     ^
111:59.12 /usr/include/math.h:156:21: note: previous definition is here
111:59.12 typedef long double double_t;
111:59.12                     ^
111:59.28 1 error generated.

Same error was reported an fixed on Freebsd:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258804

emerge --info and build-log attached.
Comment 1 Morgan Wesström 2021-10-08 14:47:46 UTC
Created attachment 743847 [details]
Complete build.log
Comment 2 Joonas Niilola gentoo-dev 2021-10-09 10:36:23 UTC
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.
Comment 3 Conrad Kostecki gentoo-dev 2021-10-09 16:48:42 UTC
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       |                     ^~~~~~~~
Comment 4 Conrad Kostecki gentoo-dev 2021-10-09 16:49:03 UTC
Created attachment 744135 [details]
build.log.gz
Comment 5 Conrad Kostecki gentoo-dev 2021-10-09 16:49:42 UTC
Created attachment 744138 [details]
emerge.info.log
Comment 6 Joonas Niilola gentoo-dev 2021-10-10 14:36:58 UTC
(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?
Comment 7 acmondor 2021-10-16 20:48:35 UTC
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.
Comment 8 acmondor 2021-10-16 20:54:33 UTC
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.
Comment 9 Ionen Wolkens gentoo-dev 2021-10-16 21:01:04 UTC
(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)
Comment 10 Joonas Niilola gentoo-dev 2021-11-04 08:34:09 UTC
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.
Comment 11 Joonas Niilola gentoo-dev 2021-11-04 12:14:51 UTC
^ 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.
Comment 12 acmondor 2021-11-08 15:34:03 UTC
This issue affects www-client/firefox-94.0.1 x86 builds in the same way and my previously supplied patch work there was well.
Comment 13 Thomas Deutschmann (RETIRED) gentoo-dev 2021-11-09 13:12:02 UTC
See comment in upstream bug report from Debian which dropped your patch in the meanwhile. It addresses x86 but breaks others.
Comment 14 Joonas Niilola gentoo-dev 2021-11-09 14:16:35 UTC
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)
Comment 15 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-09 18:33:48 UTC
(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.
Comment 16 acmondor 2021-11-10 19:23:58 UTC
(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?
Comment 17 Joonas Niilola gentoo-dev 2021-11-10 19:38:35 UTC
(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
Comment 18 acmondor 2021-11-10 21:59:53 UTC
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?
Comment 19 Joonas Niilola gentoo-dev 2021-11-11 16:31:26 UTC
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.
Comment 20 Joonas Niilola gentoo-dev 2021-11-25 19:46:55 UTC
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.
Comment 21 Thomas Deutschmann (RETIRED) gentoo-dev 2021-12-06 15:40:21 UTC
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).
Comment 22 Joonas Niilola gentoo-dev 2021-12-17 13:30:52 UTC
*** Bug 829376 has been marked as a duplicate of this bug. ***
Comment 23 Joonas Niilola gentoo-dev 2021-12-18 10:04:18 UTC
*** Bug 829376 has been marked as a duplicate of this bug. ***
Comment 24 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-12-18 10:08:14 UTC
(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.
Comment 25 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-12-18 10:09:53 UTC
There's a simpler patch on the upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1729459#c25
Comment 26 Larry the Git Cow gentoo-dev 2022-01-11 20:32:05 UTC
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(+)
Comment 27 Larry the Git Cow gentoo-dev 2022-01-13 06:33:23 UTC
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(-)
Comment 28 Morgan Wesström 2022-01-13 15:57:50 UTC
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
Comment 29 Joonas Niilola gentoo-dev 2022-01-13 16:06:55 UTC
(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!
Comment 30 Morgan Wesström 2022-01-13 16:22:58 UTC
Created attachment 762097 [details]
build.log from eeePC 901
Comment 31 Morgan Wesström 2022-01-13 16:23:32 UTC
Created attachment 762098 [details]
/proc/cpuinfo from eeePC 901
Comment 32 Morgan Wesström 2022-01-13 16:24:03 UTC
Created attachment 762099 [details]
emerge --info from eeePC 901
Comment 33 Morgan Wesström 2022-01-13 16:24:38 UTC
(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. :)
Comment 34 Joonas Niilola gentoo-dev 2022-01-20 10:32:38 UTC
96.0.2 now holds the patch for x86.