Arch Linux User Repository

*** 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.

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

Please update the PKGBUILD to conform with binutils-git(s/binutils>=2.26/binutils>=2.29/)

@giacombum. Also, I've never used yaourt before. But, out of curiosity, in a VM, I installed yaourt and successfully built gcc-git 7.0.1.r153096.7714131b8c8-1.

@giacombum. This is caused by your CHOST environment variable being set incorrectly.

My bet is: (1) in your /etc/makepkg.conf, your CHOST is set to "x86_64-unknown-linux-gnu", rather than "x86_64-pc-linux-gnu"; and (2) there's probably an /etc/makepkg.conf.pacnew file. If this is the case, if you never made custom modifications to makepkg.conf, move the .pacnew file to the .conf file. Read up at https://wiki.archlinux.org/index.php/Pacman/Pacnew_and_Pacsave, and read through pacman notifications when upgrading packages for the future.

Please comment back if this was the issue or not.

I ran into the exact failure you're having in late 2015 (you can see comments on this package) when upstream gcc git changed, and no longer expected the vendor portion of CHOST to be "unknown". On a x86_64 platform, it started expecting "pc".

In late 2015, I changed this PKGBUILD to have a workaround of changing unknown to pc, which should have worked for everyone on x86_64 platforms. On 2/15/2017, I changed the PKGBUILD to mirror the gcc (non git) package, which was able to avoid this workaround since /etc/makepkg.conf had been changed to use "pc".

You'll see in the beginning part of your build, it's properly using "x86_64-pc-linux-gnu". Then, you hit PKGBUILD line 110 (just after running "make") which is "make -C $CHOST/libstdc++-v3/doc doc-man-doxygen" which causes the failure.

I obtain the following error:

/bin/sh ./libtool --tag=CC --mode=link /tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/xgcc -B/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -mrtm -Wall -Werror -Wc,-pthread -g -march=native -O2 -fstack-protector-strong -Wl,-O1 -o libitm.la -version-info 1:0:0 -Wl,--version-script,/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc/libitm/libitm.map -rpath /usr/lib/../lib aatree.lo alloc.lo alloc_c.lo alloc_cpp.lo barrier.lo beginend.lo clone.lo eh_cpp.lo local.lo query.lo retry.lo rwlock.lo useraction.lo util.lo sjlj.lo tls.lo method-serial.lo method-gl.lo method-ml.lo x86_sse.lo x86_avx.lo futex.lo
libtool: link: /tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/xgcc -B/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -shared -fPIC -DPIC .libs/aatree.o .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o .libs/method-ml.o .libs/x86_sse.o .libs/x86_avx.o .libs/futex.o -mrtm -pthread -march=native -Wl,-O1 -Wl,--version-script -Wl,/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc/libitm/libitm.map -Wl,-soname -Wl,libitm.so.1 -o .libs/libitm.so.1.0.0
libtool: link: (cd ".libs" && rm -f "libitm.so.1" && ln -s "libitm.so.1.0.0" "libitm.so.1")
libtool: link: (cd ".libs" && rm -f "libitm.so" && ln -s "libitm.so.1.0.0" "libitm.so")
libtool: link: ar rc .libs/libitm.a aatree.o alloc.o alloc_c.o alloc_cpp.o barrier.o beginend.o clone.o eh_cpp.o local.o query.o retry.o rwlock.o useraction.o util.o sjlj.o tls.o method-serial.o method-gl.o method-ml.o x86_sse.o x86_avx.o futex.o
libtool: link: ranlib .libs/libitm.a
libtool: link: ( cd ".libs" && rm -f "libitm.la" && ln -s "../libitm.la" "libitm.la" )
true DO=all multi-do # make
make[4]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/x86_64-pc-linux-gnu/libitm'
make[3]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/x86_64-pc-linux-gnu/libitm'
make[2]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build/x86_64-pc-linux-gnu/libitm'
make[1]: Leaving directory '/tmp/yaourt-tmp-giacomo/aur-gcc-git/src/gcc-build'
make: *** x86_64-unknown-linux-gnu/libstdc++-v3/doc: No such file or directory. Stop.

Awesome. Allan's adding a version to provides did the trick.

pacman now installs these gcc*-git packages without issue now, replacing core's non-git packages.

Well... I when originally uploaded this package, it had provides/conflicts/replaces entries. So i guess my opinion is they should be there.

Nothing should be installed into /usr/local. People can have this as a standalone gcc-git package does not not replace the system version by adding this to configure:
"--program-suffix=-git --enable-version-specific-runtime-libs"

@Allan - Thanks! I didn't even get to send my pacman-dev email. :-) By the way, what are your thoughts on replacing (provides/conflicts) the core gcc* packages? Do you think it's appropriate to have a warning posted, since it doesn't seem to have caused a problem for anyone recently? Or, would you urge it to be moved into /usr/local?