Re: New external GCC toolchain ports/packages

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 ?

> 
> >
> > > googletest (needs an upstream patch to stop using signed wchar_t),
> > > and a hack to jemalloc.  I was able to build riscv as well with those
> > > same changes and am working through builds of other platforms.
> > >
> 
> Actually, both those have upstream fixes.  (For the jemalloc one, gcc is
> technically right, but because of a literal signed char argument to a
> macro.)
> 
> > > I'm happy to compare notes.  The jemalloc one is a bit weird.
> 
> I pushed non-polished changes here.  I'm working to get them reviewed.
> Please feel free to comment on any/all.
> https://github.com/rlibby/freebsd/commits/gcc9-fixes
> 
> > >
> > > --
> > > John Baldwin
> > > _______________________________________________
> > > freebsd-toolchain_at_freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> > > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe_at_freebsd.org"