Are there any problems with it? All other xbps packages are either newest version or are just a few minor patches behind. I have not seen any other rolling release distros using GCC version this old.
I ask myself the same question.
Compiling with another prefix is slow every time than I make a clean install with an upgraded gcc.
Upgrading this would currently touch 987 packages for the x86_64 glibc repo. This is a very large amount of stuff to rebuild when there are bigger issues to deal with.
I think it might have something to do with bootstrapping. In order to build GCC 5.x and later, you need a working C++11 compiler, so it introduces is an additional step when bootstrapping from GCC 3.
That said, I would love to see Void Linux provide packages for GCC 6 or 7 at some point. I tried to build GCC 6.1 from sources, but I can’t get GCC 6.1 compiled objects/archives to link, might be something to do with how Void’s binutils have been configured, but I’m not sure.
Would be nice if someone knowledgeable could take a look into getting it working and pushed out to the xbps package list.
I actually got things working for me using GCC 6.1 under Void. The problem is that GCC 6.x (and perhaps GCC5.x as well) provides its own versions of ar(1), nm(1), and ranlib(1), which are named differently (they have a gcc- prefix). You need to use these versions instead of the default binutils supplied by Void if you’re compiling with LTO. Still couldn’t get objdump(1) to work or find a working replacement, but that’s not a big deal.
The other issue I ran into is that GCC 6.1 is a lot more picky about addressing and symbol relocations on x86_64 than GCC 4.9.x when linking LTO compiled code. I had to fix up some of my libraries that have assembly code to make things work, but it was for the better.
I want to try out the new GCC 6.1 as well - Suigin, could I take a peek at your GCC 6.1 template file to save writing/editing my own (if you didn’t compile it manually).