Bug reported and fixed upstream. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
Fix isn't committed yet, so added a .patch, and modified PKGBUILD to use current trunk/master again.
Git Clone URL: | https://aur.archlinux.org/gcc-git.git (read-only, click to copy) |
---|---|
Package Base: | gcc-git |
Description: | Fortran front-end for GCC (git version) |
Upstream URL: | https://gcc.gnu.org |
Licenses: | GFDL-1.3-or-later, GPL-3.0-with-GCC-exception |
Conflicts: | gcc-fortran |
Provides: | gcc-fortran, gcc-multilib, gcc-multilib-git |
Replaces: | gcc-multilib-git |
Submitter: | Allan |
Maintainer: | IslandC0der (ptr1337) |
Last Packager: | ptr1337 |
Votes: | 15 |
Popularity: | 0.000001 |
First Submitted: | 2013-06-26 03:43 (UTC) |
Last Updated: | 2024-03-21 19:26 (UTC) |
« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 Next › Last »
Bug reported and fixed upstream. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=87672
Fix isn't committed yet, so added a .patch, and modified PKGBUILD to use current trunk/master again.
Just pushed an update. It's pinned at commit 7961f40b (trunk/master branch, but dated 2018-09-25.) I've tested it with "makepkg" and "extra-x86_64-build".
It's pinned on a commit as of 3 weeks ago, because any more recent than that (starting at 81512c36) gives a compilation failure in gcc's bootstrap stage 3. If I run this offending commit, or even trunk/master's most recent commit, manually with the commands in the PKGBUILD, it builds fine. But, as soon as I run those same commands through "makepkg" ("extra-x86_64-build" internally uses "makepkg") the compilation fails.
I wrote a very detailed post about this here: https://bbs.archlinux.org/viewtopic.php?pid=1813080
I would appreciate any help on this, including a confirmation by someone that this PKGBUILD with 7961f40b builds but that with 81512c36 or trunk/master (remove the "#commit=...") it fails.
You may have success with trunk/master by adding "--disable-bootstrap" as an option to configure. I personally don't want to run a gcc that fails bootstrap stage 3, don't recommend that you do either, and don't feel comfortable releasing one here that uses this option.
Sorry, been working on this for the past few days actually.
I just pushed a bunch of commits all at once, rebuilding starting with core's gcc. I re-did all the modifications I've made that weren't pushed yet, in small commits to show small steps, hoping to find a mistake. (BTW, only the most recent pushed commit has a rebuilt .SRCINFO, as the other commits pushed with it at the same time were intended to show steps, and not necessarily be valid within themselves, or be intermediary places to actually use.)
After fixing the issue described below, I will update to use isl-0.20. (Doing so has no effect on the error.) I wouldn't be surprised if there's one or two other modifications to make to actually build the package. (Previously, provides gave basever, this is trying out a full pkgver, etc.)
If I manually follow the steps in the PKGBUILD (run everything in prepare(), the exact same configure, and make) it compiles correctly, and gets me manually to where the end of the PKGBUILD's build() would be.
If I run extra-x86_64-build (devtools, my preference), or even makepkg, it fails to compile, with the error below. This is before the PKGBUILD's build() finishes, specifically in running plain "make".
I've been quite confused. My next step is to look through what makepkg is doing, and hopefully figure out how to reproduce the failure manually and if needed figure out if it's possible to perform an efficient bisect. I'll also be posting on the PKGBUILD forums. Might reach upstream, but I'm not thinking the issue lies there since it compiles just fine outside of makepkg.
I don't know how the other AUR building tools will do, until this is fixed. I wouldn't be surprised if they all use makepkg at some point, so my bet is they will fail.
Using makepkg or extra-x86_64-build (devtools), I get this compilation error in stage 3 of the build (which is a verification step of gcc's build process.)
Full build error here (too hard to post here, AUR takes too much of it as formatting): https://pastebin.com/28dYQqrk
=====
/build/gcc-git/src/gcc/gcc/config/i386/i386.c:19200:1: error: invalid operand in unary operation
19200 | output_fix_trunc (rtx_insn insn, rtx operands, bool fisttp)
| ^~~~~~~~~~~~~~~~
/build/gcc-git/src/gcc/gcc/config/i386/i386.c:19200:1: error: incorrect sharing of tree nodes
(ssizetype) _19
_58 = (long unsigned int) ((ssizetype) _19 <= 7 ? 7 - (ssizetype) _19 : 0);
/build/gcc-git/src/gcc/gcc/config/i386/i386.c:19200: confused by earlier errors, bailing out
make[3]: *** [Makefile:2287: i386.o] Error 1
==> ERROR: pkgver in provides is not allowed to be empty.
Since a recent system update (It might be a pacman update), I can't build this anymore:
makepkg -si
==> ERROR: pkgver in provides is not allowed to be empty.
==> ERROR: An unknown error has occurred. Exiting...
Any help?
It gives an error due to not finding x86_64-pc-linux-gnu/libcilkrts
The packaging step doesn't work
Pinned Comments
DAC324 commented on 2021-09-17 08:04 (UTC)
In addition to the jamespharvey20's sticky comment: The current GCC 12 versions are labelled "Experimental" for a reason. Development is ongoing, and there are still significant bugs. Hence, it is not recommended to use GCC 12 as a daily driver or on production systems.
At the moment, it is not even possible to build a working Linux kernel with GCC 12, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941 .
jamespharvey20 commented on 2017-02-15 04:30 (UTC) (edited on 2017-02-15 11:01 (UTC) by jamespharvey20)