New external GCC toolchain ports/packages

[Ryan Libby]

On Fri, Dec 20, 2019 at 10:15 AM Konstantin Belousov
<kostikbel at gmail.com> wrote:
>
> On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote:
> > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov <kostikbel at gmail.com> wrote:
> > >
> > > On Fri, Dec 20, 2019 at 09:24:00AM -0800, John Baldwin wrote:
> > > > On 12/19/19 12:06 PM, Ryan Libby wrote:
> > > > > On Wed, Dec 18, 2019 at 1:49 PM 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.
> > > > >>
> > > > >> --
> > > > >> John Baldwin
> > > > >
> > > > > Awesome, thanks!  I was able to get amd64 buildworld and buildkernel to
> > > > > succeed with just a few changes, and none to the port.  I'll work on
> > > > > getting the changes in.
> > > >
> > > > I have been able to get it building as well, mostly by muting a few
> > > > warnings, adding libcompiler_rt to rtld's link for i386, disabling
> > > I am curious about the rtld issue.  Can you show me the pristine error with
> > > gcc, please ?
> >
> > For me, it's gcc generates __udivmoddi4 for the -m32 build but we used
> > -nostdlib, and we get a link error.  My hack right now is to explicitly
> > link libgcc, but I don't think this is what we are intending to do
> > because we seem to go through effort to reimplement other libgcc
> > functions.
> >
> > Here's the text:
> > --- ld-elf32.so.1.full ---
> > /usr/local/bin/x86_64-unknown-freebsd13.0-ld: rtld_printf.o: in
> > function `ksprintn':
> > /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:115: undefined
> > reference to `__udivmoddi4'
> > /usr/local/bin/x86_64-unknown-freebsd13.0-ld:
> > /usr/src/freebsd/libexec/rtld-elf/rtld_printf.c:117: undefined
> > reference to `__udivmoddi4'
> > collect2: error: ld returned 1 exit status
> > *** [ld-elf32.so.1.full] Error code 1
> >
> > You can see my hack at the link below.  I'm not sure what the
> > right solution is.
> Does changing the base type from int to u_int help ?

It does not; it fails in the same way.