lang/gcc13: Add port

[salvadore]

Summary

GCC, the GNU Compiler Collection, supports a number of languages.
This port installs the C, C++, and Fortran front ends as gcc13,
g++13, and gfortran13, respectively.

This is the first release from the GCC 13 series.
It largely is a copy of lang/gcc13-devel, with release-specific
modifications from lang/gcc12.

Common issues that could happen when porting code to GCC 13:
https://gcc.gnu.org/gcc-13/porting_to.html

Changes: https://gcc.gnu.org/gcc-13/changes.html

[salvadore]

@gerald: I have already created the lang/gcc14-devel port without issues, but while creating lang/gcc13 I noticed that there were a few things to be careful to, such as declaring the conflict between lang/gcc13-devel and lang/gcc13. Thus I thought that a review from you might be useful in this case. Have I forgotten anything?

I know we also need to update bsd.gcc.mk, but I guess we can do it after having created the ports and verified that everything is fine.

By the way, I have tested successfully this patch with poudriere on {i386,amd64} FreeBSD-{12.4,13.2,14.0}.

[salvadore]

I have tested it successfully on aarch64 13.2 too, but I have got a plist error on aarch64 14.0:

====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: share/info/gcc13/libitm.info
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1

So a bit more work is required here. I will also check lang/gcc13-devel, as this is the first time I am actually testing gcc ports personally on aarch64.

[dan.mcgregor_usask.ca]

lang/gcc13/Makefile

98

One change I've been sitting on for a long time, and have been meaning to submit, is adding --enable-initfini-array here. I don't know if it's changed since I last tested it, but GCC doesn't seem to detect it on its own. FreeBSD has supported it for years at this point.

Seems as good a time as any to send it up.

[dan.mcgregor_usask.ca]

lang/gcc13/files/patch-libcxxrt

2

Also reminds me I have a somewhat more upstreamable version of this, that only does this for FreeBSD targets. I'll try to send it.

[salvadore]

lang/gcc13/Makefile

98

Thanks, this is a good idea and we will try to enable initfini-array. However, the aim of this review is to create the lang/gcc13 port only: I prefer to make it better later. GCC ports are complex and it is always better to do things one step at a time, usually starting from the *-devel ports.

Rather than forcing the option, I would prefer to fix the dection test. I have found the code that detects if initfini-array is supported or not: it looks very simple, it only checks which libc version is the OS using. It should be very easy to patch, and hopefully also to upstream. Are you able to tell me what is the first version of libc in FreeBSD that has initfini-array support?

lang/gcc13/files/patch-libcxxrt

2

Great, thanks. Please let me know if you manage to get it upstreamed.

[dan.mcgregor_usask.ca]

lang/gcc13/Makefile

98

Fair enough about changes like that; looks like FreeBSD 10.0 was the first release with initfini array support.

[dan.mcgregor_usask.ca]

lang/gcc13/Makefile

98

Ah, I just looked myself. Yeah, it looks like the configuration check for initfini is super easy to add. Just set the default for freebsd >= 10.0 to enabled. Probably something for upstream.

[salvadore]

In D39841#907369, @salvadore wrote:

I have tested it successfully on aarch64 13.2 too, but I have got a plist error on aarch64 14.0:

====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: share/info/gcc13/libitm.info
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1

So a bit more work is required here. I will also check lang/gcc13-devel, as this is the first time I am actually testing gcc ports personally on aarch64.

My mistake: I was looking at the wrong log (the issue is for the lang/gcc*-devel ports, which I am already fixing). This patch builds successfully on aarch64 too.

lang/gcc13/Makefile

98

Thank you very much. Knowing the first version supporting initfini array will be very useful.

[gerald]

Hi Lorenzo,

I had a look and nothing immediately came to my mind as missing.

As a "trick", which it seems you have done already anyway, when I had a new lang/gcc port I usually did a diff against its corresponding -devel port and the N-1 version lang/gcc port. That caught most changes required.

As an additional note, and this is something we did not do so far, there is an area where Git is inferior to SVN: history. I believe it is useful, if not important, for gcc$LATEST-devel to reflect as much of the history of the lang/gcc* family as possible. Creating a new port loses that. Sadly Git lacks git cp, though at least it has git mv. So what I recommend is to git mvthe latest port that has the history dating back several major versions to lang/gcc14-devel and create lang/gcc13 and lang/gcc13-devel as new ports. Not great, but without that git log and git blame are not exactly useful.

lang/gcc13/Makefile

98

Dan, I have commit rights upstream: If you want to copy me (as [e-mail]) on your upstream patch submission and note that I volunteer to push your patch, that may help.

[salvadore]

In D39841#907758, @gerald wrote:

I had a look and nothing immediately came to my mind as missing.

As a "trick", which it seems you have done already anyway, when I had a new lang/gcc port I usually did a diff against its corresponding -devel port and the N-1 version lang/gcc port. That caught most changes required.

Indeed, I used diff.

As an additional note, and this is something we did not do so far, there is an area where Git is inferior to SVN: history. I believe it is useful, if not important, for gcc$LATEST-devel to reflect as much of the history of the lang/gcc* family as possible. Creating a new port loses that. Sadly Git lacks git cp, though at least it has git mv. So what I recommend is to git mvthe latest port that has the history dating back several major versions to lang/gcc14-devel and create lang/gcc13 and lang/gcc13-devel as new ports. Not great, but without that git log and git blame are not exactly useful.

Unfortunately, I have already created lang/gcc14-devel: https://cgit.freebsd.org/ports/commit/?id=4dd6b46b731c441ba3879486381dac1ffbabe232.

We can implement your suggestion when lang/gcc15-devel is out. However, I am unsure this is a good idea. To transfer the history as you would like to do, I think you need to commit right after git mv and then recreate the old port in the next commit: thus, using git log --follow <new port> you get the new history indeed. However, this creates a commit where a port has been removed: we would need to document it into MOVED, then resurrect the port immediately in the next commit. This makes the history of MOVED a bit messy. Bisecting might also get harder: the bisection might try to use our intermediate commit. It is true that the missing port would not correspond to GCC_DEFAULT so there are little chances that anyone gets into any issue, but it is still a bit weird.

I think writing that the new port is created as a copy of another port in the commit message is simpler and good enough. I do not think anyone inspecting the history of lang/gcc20-devel will ever need to go back to lang/gcc17-devel: switching from a port to another manually seems easy enough to me as long as there are only a few switches.

Also note that git log lang/gcc*-devel works.

An even better strategy would be to manage to get FreeBSD into the CI of GCC, so that we do not need the *-devel ports any more. As you might remember, we made a small attempt, but we did not get anywhere. The only thing I remember is that this site might be useful: https://builder.sourceware.org/. I will try to research into it again when I have time.

[salvadore]

In D39841#907764, @salvadore wrote:

Also note that git log lang/gcc*-devel works.

Actually, you would probably enjoy git log lang/gcc* even more.