Page MenuHomeFreeBSD

Add freebsd-gcc6 port.
ClosedPublic

Authored by jhb on Oct 24 2019, 9:47 PM.

Details

Summary

This port is basically identical to the existing <arch>-gcc ports
that use GCC6. However, they use flavors for the different
architectures instead of slave ports. It also includes the external
toolchain makefile and thus subsumes the <arch>-xtoolchain-gcc
port into the new packages.

This should permit us to have ports for different major versions of
GCC (e.g. a freebsd-gcc9 port).

aarch64-gcc6 disables LTO support to work with aaarch64-binutils
which builds a static ld.bfd binary by default which is unable to work
with LTO.

Test Plan
  • poudriere bulk -t builds ok
  • able to build a world with aarch64-gcc6

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb created this revision.Oct 24 2019, 9:47 PM
jhb added a comment.Oct 24 2019, 9:52 PM

I know that llvm uses separate xtoolchain ports, but those depend on the stock llvm. In this case we are already patching GCC to be a system compiler, so I wonder if it might not be better to fold the xtoolchain bits into the freebsd6-gcc port itself and just have <arch>-gcc6 install the toolchain file. Then it's kind of nice because to get cross toolchain "foo" (e.g. mips-gcc6) you 'pkg install mips-gcc6'.

jhb added a comment.Oct 24 2019, 9:54 PM

We could perhaps collapse the devel/<arch>-binutils ports into a single devel/freebsd-binutils that used FLAVORS, but that would still be a slave of devel/binutils, so not sure how that would actually work? Might be simplest to just let them be for now?

Also, if this approach works, I'd probably like to do something similar with base/gcc where it becomes base/gcc6 and we have a base/gcc9, etc.

jhb updated this revision to Diff 63658.Oct 25 2019, 12:13 AM

Disable LTO for aarch64-gcc.

LTO requires dynamic binutils and aarch64-binutils is forced to static
linking. (Is this still required for qemu uesr mode since aarch64
switched to lld?)

I have always hated the fact that the masterport was (for hysterical raisins?) powerpc64. Thanks for attempt to undo that mess.

I'll give it a shot here locally (with the X86 string) and see what happens.

devel/freebsd-gcc6/Makefile
99 ↗(On Diff #63658)

I would prefer "X86" to "I386" here (et seq.) to be more consistent with other ports in the tree.

linimon added inline comments.Oct 25 2019, 5:08 AM
devel/freebsd-xtoolchain-gcc6/Makefile
1 ↗(On Diff #63658)

Knowing that this was the following would have saved me some time:

  • devel/powerpc64-xtoolchain-gcc/Makefile 2019-09-19 02:03:14.896243000 +0000

+++ devel/freebsd-xtoolchain-gcc6/Makefile 2019-10-24 23:38:38.416300000 +0000

jhb added inline comments.Oct 25 2019, 4:50 PM
devel/freebsd-gcc6/Makefile
99 ↗(On Diff #63658)

base/gcc already uses I386 in its (nearly identical) plist. If you look at the affected filenames in the plist, most of them have "i386" in the pathname or filename (e.g. config/i386/*). The ARM/AARCH64 naming is somewhat similar in that the 64-bit version installs support for both, but the 32-bit version only includes support for 32-bit.

126 ↗(On Diff #63658)

Oops, I forgot to remove these bits which ended up not being needed (I used the xx target for testing so I could easily undo it if it broke plist stuff)

devel/freebsd-xtoolchain-gcc6/Makefile
1 ↗(On Diff #63658)

It's an 'svn cp' in the working tree (and it does say so in the web ui), but this is how it was uploaded from 'arc diff --create' :-/

jhb updated this revision to Diff 63667.Oct 25 2019, 4:52 PM

Trim some unneeded post-install steps.

I can confirm that these all build on my test box.

w/rt the 'I386' string, we seem to have an incompatibility between src and ports. I don't think it's worth holding up progress to look into it.

jhb added a comment.Oct 31 2019, 10:16 PM

I can confirm that these all build on my test box.
w/rt the 'I386' string, we seem to have an incompatibility between src and ports. I don't think it's worth holding up progress to look into it.

Do you have any thoughts on merging the xtoolchain package into the freebsd6-gcc package (per my first comment)?

jhb updated this revision to Diff 64012.Nov 6 2019, 6:40 PM

Merge the xtoolchain file into freebsd-gcc6 itself.

jhb retitled this revision from Add freebsd-gcc6 and freebsd-xtoolchain-gcc6 ports. to Add freebsd-gcc6 port..Nov 6 2019, 6:44 PM
jhb edited the summary of this revision. (Show Details)
jhb edited the test plan for this revision. (Show Details)
imp accepted this revision.Nov 6 2019, 6:44 PM

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

This revision is now accepted and ready to land.Nov 6 2019, 6:44 PM
jhb added a subscriber: brooks.Nov 6 2019, 6:45 PM

@brooks suggested he would consider merging the llvm-xtoolchain ports into the llvm ports as well. I think it is nice that you can 'pkg install <foo>' to get the bits for 'make CROSS_TOOLCHAIN=<foo>'

jhb added a comment.Nov 6 2019, 6:46 PM
In D22147#486621, @imp wrote:

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

What I would really like is to have a shared pkg-plist and separate pkg-plist.${TARGETARCH} files. There doesn't seem to be an easy way to do this currently.

In D22147#486624, @jhb wrote:

@brooks suggested he would consider merging the llvm-xtoolchain ports into the llvm ports as well. I think it is nice that you can 'pkg install <foo>' to get the bits for 'make CROSS_TOOLCHAIN=<foo>'

I'm happy to do this, but I do like to batch changes to llvm ports other than llvm-devel so I'll probably queue the change for inclusion with other updates (e.g. patches for riscv support.)

mat added inline comments.Nov 7 2019, 7:55 AM
devel/freebsd-gcc6/Makefile
34 ↗(On Diff #64012)

The FLAVORS section goes just after dependencies.

jhb updated this revision to Diff 64045.Nov 7 2019, 5:53 PM
  • Move FLAVORS section earlier.
This revision now requires review to proceed.Nov 7 2019, 5:53 PM
brooks added a comment.Nov 7 2019, 6:10 PM
In D22147#486635, @jhb wrote:
In D22147#486621, @imp wrote:

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

What I would really like is to have a shared pkg-plist and separate pkg-plist.${TARGETARCH} files. There doesn't seem to be an easy way to do this currently.

The thing you could do now would be to use PLIST_FILES either directly in a Makefile or with a != assignment that pulled them out of some pkg-plist.${ARCH}. I do the former for sanitizer runtimes in the llvm ports. It's ugly, but works.

jhb added a comment.Nov 7 2019, 6:25 PM

I think all you have to do to support multiple files in PLIST would be one of the following in the generate-plist target in bsd.port.mk:

  • Remove the '-f' check and if a port lists a non-existent file in PLIST, let sed fail with an error. Note that sed will already work fine with multiple files given on the command line where PLIST is already used.
  • Use a .for around the -f check and sed invocation.

Both of these seem pretty small. I suspect the -f check is required so ports that use PLIST_FILES or PLIST_DIRS don't have to explicitly set an empty PLIST, so probably the latter approach is best.

jhb added a comment.Tue, Nov 12, 11:58 PM

Any further thoughts? I could perhaps work on the PLIST thing as a followup and then split up the plist after that

brooks accepted this revision.Thu, Nov 14, 9:59 PM

I think this is ready to go as is. PLIST cleanups can wait IMO.

This revision is now accepted and ready to land.Thu, Nov 14, 9:59 PM
imp added a comment.Fri, Nov 15, 12:23 AM

I think this is ready to go as is. PLIST cleanups can wait IMO.

yea, my comments in this area were based on a flawed understanding of things...

imp accepted this revision.Fri, Nov 15, 12:23 AM

A pre-commit hook says I can't commit anything using FLAVORS without portmgr approval, so adding portmgr.

swills accepted this revision.Tue, Nov 19, 1:29 AM
This revision was automatically updated to reflect the committed changes.