Created attachment 202303 [details] patch GCC 6 can be built using base GCC, so switch from GCC 5 to GCC 6 for building newer GCC versions. Hardware sponsored by IntegriCloud.
So, I thought a bit more about this, and couldn't we USE_GCC=yes for all ports different from gcc8 / gcc8-devel which are the default versions in the ports tree? And only have that dependency on gcc6 for gcc8 / gcc8-devel ? (We generally try to have USE_GCC=yes where possible, and refer to specific versions only if unavoidable.) Or am I missing something? If you agree I can make this change and commit (since it appears you do not have write access to the ports tree). If not, let's see what makes most sense. I'm open - whatever makes sense. ;-)
(In reply to Gerald Pfeifer from comment #1) There are three issues with it. 1. Some people may set non-default GCC version, which will cause a dependency loop. That's why it's better to use USE_GCC=$THE_LAST_VERSION_BUILDING_WITH_BASE_GCC. 2. Having USE_GCC=6 will help to make sure that new GCC versions (in -devel ports) will build with GCC 6, so that we won't have to add another GCC to the chain (base GCC -> GCC 6 -> GCC 8 -> GCC 9). Having GCC 6 in the middle is enough PITA :) 3. Problems like what happened with the switch to GCC 8 (when the committer forgot to change USE_GCC to 5 for GCC 8 port) won't happen again, since the -devel port will have correct USE_GCC.
(In reply to Piotr Kubaj from comment #2) > 1. Some people may set non-default GCC version, which will cause a > dependency loop. That's why it's better to use > USE_GCC=$THE_LAST_VERSION_BUILDING_WITH_BASE_GCC. Indeed, that's the one point I've been wondering about myself. Since you share the concern, let's nail it down to GCC 6, which is already a good improvement over GCC 5. That said, this doesn't absolutely depend on PR 235964 so we could go ahead and apply your patch as is. Any major concerns with that? (I understand that temporarily this will require GCC 5 and 6 for some users.)
(In reply to Gerald Pfeifer from comment #3) You could commit it right now, but this will mean that users will need to build two GCC releases before building GCC 8, so I'd rather switch GCC 6 to base GCC. Building GCC 5 now before GCC 8 is enough PITA, building GCC 5, then 6 is PITA^2. It will make fixing ports much more painful, so I'd rather you don't do it.
Created attachment 202498 [details] patch I succeeded in building GCC 7 and GCC 8 with base GCC. The key is to drop -O2, since that crashes our GCC. It's fine to use -O1. Unfortunately, GCC 9 still can't build with our GCC, so use GCC 8 to build it for now.
PR 235964 generally has been addressed, we're just working on (a) simplifying things a bit, and (b) promoting (part of) the same fix to other lang/gcc* ports, but for the sake of this exercise, we're good, thus removing the dependency.
Thank you for the updated patch. Do we really, really need all of CXXFLAGS_FOR_TARGET="-O1" CFLAGS_FOR_TARGET="-O1" BOOT_CFLAGS="-O1" for the build to succeed? (I assume you have read https://gcc.gnu.org/install/build.html ?) CFLAGS_FOR_TARGET="-O1" would impact performance of the production build in the end, wouldn't it? On the lang/gcc9-devel change, I'd prefer to keep USE_GCC=yes for the time being. I know I made an omission when updating the default to GCC 8, but ignoring that, USE_GCC=yes is the better option for users and possibly one less compiler to build. And somehow the bit around enabling Go sneaked in :-), which I'll happy to take separately (probably going to commit on Monday when I'll also plan to commit the change to the MULTILIB-specific code we discussed in the other report). And I don't think the MULTILIB-specific changes are actually correct: The directory ${STAGEDIR}${TARGLIB32}/gcc${SUFFIX} should be created when moving, not before, or we'll actually get ${STAGEDIR}${TARGLIB32}/gcc${SUFFIX}/gcc${SUFFIX} , won't we? Let me take care of gcc9-devel and the MULTILIB-specific changes in the coming days (about a week perhaps), which will result in several of your issues/requests addressed and make the core of the patch rather smaller; okay?
(In reply to Gerald Pfeifer from comment #7) Yes, we need to switch to -O1, I know it will impact the performance, but it enables us to remove the dependency on GCC5 (or 6). I already talked to linimon@ about it and he agrees with me. We need all those three env, I tested build without using only two of them (in each combination) and got segfaults. I saw the GCC link, ran bootstrap-O1 and it made the compiler segfault just the same. As for Go, that was my mistake, don't commit it yet :) This is my WIP, the upstream bug is here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 You're right, ${MKDIR} isn't needed. I didn't catch it, because gcc7 and gcc8 ports actually built fine: https://talos.anongoth.pl/data/powerpc64-default/2019-03-02_09h37m49s/logs/gcc8-8.3.0.log https://talos.anongoth.pl/data/powerpc64-default/2019-03-02_09h37m49s/logs/gcc7-7.4.0_1.log
Also, if GCC 8 becomes the new GCC 5 (used for building GCC 9 and newer), than USE_GCC=8 is not bad, since each powerpc64 will likely have GCC 8 installed anyway.
A commit references this bug: Author: gerald Date: Thu Mar 7 09:55:53 UTC 2019 New revision: 494921 URL: https://svnweb.freebsd.org/changeset/ports/494921 Log: No longer require a not too old version of GCC to build on powerpc64, but rely on the system compiler (even if that means we need to be explicitly conservative when it comes to optimizations). [1] Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. [2] Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there. PR: 235975 [1], 235964 [2], 231804 [2] Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [2] Changes: head/lang/gcc8/Makefile head/lang/gcc8/pkg-descr
A commit references this bug: Author: gerald Date: Fri Mar 8 12:12:21 UTC 2019 New revision: 495037 URL: https://svnweb.freebsd.org/changeset/ports/495037 Log: Update to the 20190307 snapshot of GCC 7.4.1. No longer require a not too old version of GCC to build on powerpc64, but rely on the system compiler (even if that means we need to be explicitly conservative when it comes to optimizations). [1] PR: 235975 [1] Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1] Changes: head/lang/gcc7-devel/Makefile head/lang/gcc7-devel/distinfo
A commit references this bug: Author: gerald Date: Sat Mar 9 15:20:30 UTC 2019 New revision: 495172 URL: https://svnweb.freebsd.org/changeset/ports/495172 Log: Update to the 20180308 snapshot of GCC 8.3.1. No longer require a not too old version of GCC to build on powerpc64, but rely on the system compiler (even if that means we need to be explicitly conservative when it comes to optimizations). [1] Sync pkg-descr with lang/gcc7-devel, in particular after r442530 there. PR: 235975 [1] Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1] Changes: head/lang/gcc8-devel/Makefile head/lang/gcc8-devel/distinfo head/lang/gcc8-devel/pkg-descr
A commit references this bug: Author: gerald Date: Sun Mar 10 05:22:49 UTC 2019 New revision: 495227 URL: https://svnweb.freebsd.org/changeset/ports/495227 Log: No longer require a not too old version of GCC to build on powerpc64, but rely on the system compiler (even if that means we need to be explicitly conservative when it comes to optimizations). [1] Simplify the creation of the multilib-related sub-directory tree on powerpc64 and avoid leaving an empty directory behind on the way. [2] PR: 235975 [1], 235964 [2], 231804 [2] Submitted by: Piotr Kubaj <pkubaj@anongoth.pl> [1] Discussed with: Piotr Kubaj <pkubaj@anongoth.pl> [2] Changes: head/lang/gcc7/Makefile
Hi Piotr, I believe we have now covered everything around the GCC 7 and GCC 8 based ports, and while there are minor tweaks I plan on making to lang/gcc9-devel and lang/gcc6 in the coming days, I believe this report has been addressed. Please advise if there's anything missing, different than what we discussed (where you disagree), or incorrect/not working in your environment. Thanks for the reports and good interactions; it's been a pleasure!
For the record, I do not agree to drop -O2 for the target gcc. For the bootstrap compiler, yes, but not for the bootstrapped compiler. I mentioned in 235964 'feel free to change what fits you best', yes, but this was not meant to change gcc internal optimization. Since it is a port, well, do what needs to be done.