Bug 235975 - lang/gcc: switch GCC 7 and 8 to use base GCC for build, GCC 9 to GCC 8
Summary: lang/gcc: switch GCC 7 and 8 to use base GCC for build, GCC 9 to GCC 8
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-23 22:41 UTC by Piotr Kubaj
Modified: 2019-03-10 22:00 UTC (History)
2 users (show)

See Also:


Attachments
patch (2.19 KB, patch)
2019-02-23 22:41 UTC, Piotr Kubaj
no flags Details | Diff
patch (4.28 KB, patch)
2019-03-02 08:39 UTC, Piotr Kubaj
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Kubaj freebsd_committer 2019-02-23 22:41:55 UTC
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.
Comment 1 Gerald Pfeifer freebsd_committer 2019-02-26 20:46:35 UTC
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. ;-)
Comment 2 Piotr Kubaj freebsd_committer 2019-02-27 07:28:41 UTC
(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.
Comment 3 Gerald Pfeifer freebsd_committer 2019-02-27 22:21:05 UTC
(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.)
Comment 4 Piotr Kubaj freebsd_committer 2019-02-28 12:14:22 UTC
(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.
Comment 5 Piotr Kubaj freebsd_committer 2019-03-02 08:39:41 UTC
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.
Comment 6 Gerald Pfeifer freebsd_committer 2019-03-02 12:42:30 UTC
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.
Comment 7 Gerald Pfeifer freebsd_committer 2019-03-02 13:07:49 UTC
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?
Comment 8 Piotr Kubaj freebsd_committer 2019-03-02 15:35:36 UTC
(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
Comment 9 Piotr Kubaj freebsd_committer 2019-03-02 16:32:07 UTC
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.
Comment 10 commit-hook freebsd_committer 2019-03-07 09:56:17 UTC
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
Comment 11 commit-hook freebsd_committer 2019-03-08 12:13:15 UTC
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
Comment 12 commit-hook freebsd_committer 2019-03-09 15:21:20 UTC
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
Comment 13 commit-hook freebsd_committer 2019-03-10 05:22:57 UTC
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
Comment 14 Gerald Pfeifer freebsd_committer 2019-03-10 11:12:15 UTC
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!
Comment 15 Andreas Tobler freebsd_committer 2019-03-10 21:59:49 UTC
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.