| Git Clone URL: | https://aur.archlinux.org/gcc-git.git (read-only) |
|---|---|
| Package Base: | gcc-git |
| Description: | Go front-end for GCC (git version) |
| Upstream URL: | http://gcc.gnu.org |
| Licenses: | |
| Conflicts: | |
| Provides: | |
| Submitter: | Allan |
| Maintainer: | jamespharvey20 |
| Last Packager: | jamespharvey20 |
| Votes: | 13 |
| Popularity: | 0.452724 |
| First Submitted: | 2013-06-26 03:43 |
| Last Updated: | 2018-12-29 03:01 |
Should flex and bison be added as build depends? It took me a while to figure this out when trying to build a Docker image with this package installed. Or am I just a moron and they are included in the implied base-devel dependency?
Edit: looked it up. Nevermind, I'm the idiot.
Upstream revision 267034 (git commit 40caaded 2018-12-11) renamed target 'install-gnatlib' to 'install-libada'.
PKGBUILD has been updated.
The comment and upstream bugreport I made on 2018-12-25 was a red herring. Those errors regarding 'gnatdll' and 'rts/standard.ads.h' appear even on building core's 8.2.1+20180831-1, but do not make the build fail. The "make... ada.install-{common,info}" command was succeeding, even with those errors. It was the "make... install-gnatlib" command after that which was causing the build to fail.
git commit 40caaded (2018-12-11) breaks "make ... ada.install-{common,info}" in package_gcc-ada-git().
Reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88591
Temporarily, use its parent by appending "#commit=b686c391" to the git source url to successfully build. I'm expecting this will be a quick upstream fix, so won't push a PKGBUILD with this commit baked in, unless it isn't fixed quickly upstream.
Thanks, bz87672.patch has been removed.
Yesterday, I attempted building 9.0.0.r166204.2c4e6da263b, and got a failure in "package_gcc-ada-git()", including:
I know 9.0.0.r164385.7961f40be4b worked, on 10/21. I'm trying again, but I'm expecting a failure even on current master. Unless current master now works, there is probably either: an upstream bug introduced in the past 2 months that gets triggered by the way Arch core builds gcc; or an upstream change to 9.0.0 which would necessitate a change to the way Arch builds.
bz87672.patch can be removed, it was applied upstream.
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?
Pinned Comments
jamespharvey20 commented on 2017-02-15 04:30
*** STICKY ***
These gcc*-git packages replace core's gcc* (non-git) packages. Technically, replacing the system gcc-libs can be dangerous. The possibility of a new upstream gcc git commit breaking your system isn't zero. When you compile and install this, you're using the latest git source, so you may be the first Arch user to be using that particular commit.
In practice, I haven't seen an Arch user report such a problem for many years. Just understand that if installing these packages causes your computer to eat you, don't have your loved ones blame me. Oh, and know that if things go wrong, all you *should* have to do is uninstall the git version and go back to a previously working git version or even the core version. You might be able to do this while your system is still running, or you might have to do something like boot off an Arch ISO CD.