On Fri, Dec 20, 2019 at 09:51:15AM -0800, Ryan Libby wrote: > On Fri, Dec 20, 2019 at 9:31 AM Konstantin Belousov <kostik...@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 <j...@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-toolch...@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > > To unsubscribe, send any mail to > > > "freebsd-toolchain-unsubscr...@freebsd.org" _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"