Add freebsd-gcc6 port.

[jhb]

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

[jhb]

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]

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]

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?)

[linimon]

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]

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]

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]

Trim some unneeded post-install steps.

[linimon]

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]

In D22147#484948, @linimon wrote:

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]

Merge the xtoolchain file into freebsd-gcc6 itself.

[imp]

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

[jhb]

@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]

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.

[brooks]

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]

devel/freebsd-gcc6/Makefile

34 ↗

(On Diff #64012)

The FLAVORS section goes just after dependencies.

[jhb]

• Move FLAVORS section earlier.

[brooks]

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]

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]

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

[brooks]

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

[imp]

In D22147#489200, @brooks wrote:

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...

[jhb]

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