Re: New external GCC toolchain ports/packages

On 12/18/19 4:16 PM, Mark Millard wrote:
> 
> 
> On 2019-Dec-18, at 13:48, John Baldwin <jhb_at_freebsd.org> wrote:
> 
>> In the interest of supporting newer versions of GCC for a base system
>> toolchain, I've renamed the external GCC packages from <arch>-gcc
>> to <arch>-gcc6.  These are built as flavors of a new devel/freebsd-gcc6
>> port.  The xtoolchain package is not used for these new packages, instead
>> one does 'pkg install mips-gcc6' to get the GCC 6.x MIPS compiler and
>> uses 'CROSS_TOOLCHAIN=mips-gcc6'.  I've also gone ahead and updated this
>> compiler to 6.5.0.
>>
>> I will leave the old ports/packages around for now to permit an easy
>> transition, but going forward, the <arch>-gcc6 packages should be preferred
>> to <arch>-xtoolchain-gcc for all but riscv (riscv64-gcc and riscv64-xtoolchain-gcc
>> are separate from the powerpc64-gcc set of packages).
>>
>> In addition, I've also just added a devel/freebsd-gcc9 package which
>> builds <arch>-gcc9 packages.  It adds powerpc and riscv flavors relative
>> to freebsd-gcc6 and uses GCC 9.2.0.  To date in my testing I've yet to
>> be able to finish a buildworld on any of the platforms I've tried
>> (amd64, mips, sparc64), but the packages should permit other developers
>> to get the tree building with GCC 9.  To use these packages one would do
>> something like:
>>
>> # pkg install amd64-gcc9
>> # make buildworld CROSS_TOOLCHAIN=amd64-gcc9
>>
>> You can install both the gcc6 and gcc9 versions of a package at the same
>> time, e.g. amd64-gcc6 and amd64-gcc9.  Having different packages for major
>> versions is similar to llvm and will also let us keep a known-good
>> toolchain package for older releases while using newer major versions on
>> newer FreeBSD releases (e.g gcc9 for 13.0 and gcc6 for 12.x).
>>
>> I do plan to switch the default toolchains for make universe/tinderbox
>> for targets using <arch>-xtoolchain-gcc based on GCC 6 over to the
>> freebsd-gcc6 variants in the next week or so.
>>
> 
> How about base/binutils and base/gcc ? Is their (future?) status
> changed by any of this activity?

I plan to rename base/gcc to base/gcc6 (and update it to 6.5) and then
add a base/gcc9 that would provide GCC 9 as /usr/bin/cc.

-- 
John Baldwin