Package Details: gcc-git 6.0.0.r143660.7b0b2ad-1

Git Clone URL: https://aur.archlinux.org/gcc-git.git (read-only)
Package Base: gcc-git
Description: The GNU Compiler Collection - C and C++ frontends (developmental version)
Upstream URL: http://gcc.gnu.org
Licenses: GPL, custom, LGPL, FDL
Groups: base-devel
Conflicts: gcc
Provides: gcc
Submitter: Allan
Maintainer: jamespharvey20
Last Packager: jamespharvey20
Votes: 10
Popularity: 0.260661
First Submitted: 2013-06-26 03:43
Last Updated: 2015-12-19 22:58

Required by (924)

Sources (2)

Latest Comments

janisozaur commented on 2016-02-25 11:05

It seems ISL 0.16.1 is available now and https://gcc.gnu.org/install/prerequisites.html mentions it as a compatible, can you check & update the PKGBUILD?

See https://groups.google.com/forum/#!topic/isl-announce/i8PTGG0ZbzE for announcment

jamespharvey20 commented on 2015-12-13 21:00

So, it might be easy enough to patch config.guess:1041, if we wanted to deviate from upstream if they won't revert it. If you'd like, I can see if that works.

jamespharvey20 commented on 2015-12-13 20:52

Think this is where it came from:

https://lists.gnu.org/archive/html/config-patches/2015-06/msg00017.html

^^^ "This is a minimally invasive change"

http://git.savannah.gnu.org/cgit/config.git/commit/?id=ca9bfb8cc75a2be1819d89c664a867785c96c9ba

Then brought downstream into GCC:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c14bac81551d6769741c2b1cc55e04d94fe8d3a7

Allan commented on 2015-12-13 10:48

Thanks - I'll look into why this has changed. Changing the CHOST like that is a bad idea (TM), so I'll figure out why this has occurred.

jamespharvey20 commented on 2015-12-13 10:45

Sure. The first instance I ran into it was at PKGBUILD::build(), at "make -C $CHOST/libstdc++-v3/doc doc-man-doxygen". It failed, expecting there to be a "${srcdir}/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/doc" directory. But, instead, "${srcdir}/gcc-build/" has:
build-x86_64-pc-linux-gnu/
prev-x86_64-pc-linux-gnu/
stage1-x86_64-pc-linux-gnu/
x86_64-pc-linux-gnu/

So, it doesn't actually detect CHOST using "unknown" and give an error. It makes the directories (at least on my system) with "pc" rather than "unknown", so every instance PKGBUILD uses $CHOST points to a non-existant directory.

Off to bed. 6am here.

Allan commented on 2015-12-13 10:20

Can you point me at where GCC now expects the vendor to be set to something other than "unknown"?

jamespharvey20 commented on 2015-12-13 09:44

NOTE: GCC previously expected to see CHOST declaring vendor to be "unknown" on my system. (i.e. CHOST='x86_64-unknown-linux-gnu'.) On my system, GCC is now expecting to see vendor "pc". (i.e. CHOST='x86_64-pc-linux-gnu'.) Added a workaround so if Arch declares CHOST to be 'x86_64-unknown-linux-gnu' or 'i686-unknown-linux-gnu', it changes the 'unknown' portion to 'pc'.

If this workaround fails on your system, you will receive a compilation error due to a non-existant directory. If this happens, you may have to change the PKGBUILD so _CHOST declares vendor as "softfloat", "hardfloat", or "unknown". (The directory it complains is missing will tell you what vendor value it's expecting.)

jamespharvey20 commented on 2015-12-13 09:38

My apologies. Unexpected multiple severe family health issues. (All turned out well.) Just pushed multiple updates that should take care of everything. There are one or two namcap errors that should be fairly non-consequential documented in the PKGBUILD that I'm going to look into and take care of tomorrow.

thatbrod commented on 2015-12-01 11:56

Could the owner please either orphan or update the package?

polymer commented on 2015-10-20 13:29

Current version fails when applying patches in prepare(), after commenting these I believe the script tries to use a MakeFile that doesn't exist. I think the PKGBUILD script is buggy or old.

All comments