I do think it probably makes sense to divorce the baremetal GCC ports from powerpc64-gcc and let powerpc64-gcc just be the basis for FreeBSD-specific toolchains.
On 5/19/19 10:48 AM, James Shuriff wrote: > I have a Raspberry Pi 3 model b. I use the LLVM toolchain to build the system > but the GNU toolchain is required to build U-Boot. U-Boot uses global > register variables and LLVM doesn't support this. sysutils/u-boot-pine64 does > use aarch64-none-elf-gcc, for the same reason. The family is allwinner64 and > that's set to use aarch64-none-elf-gcc. Here is an article explaining the > feature U-Boot uses that's not in LLVM (the reason GNU is required for > building it): > > https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html > > Aarch64 is a Tier 2 architecture. The toolchain should have an active > maintainer (the maintainer is listed as po...@freebsd.org). I've opened a bug > report for the bugs in the Makefile. We should be using a newer toolchain or > separate arm-none-eabi and aarch64-none-elf from powerpc64. I am guessing the > Makefile bugs occurred because the original designer didn't intend on > powerpc64-gcc being used for targets like arm-none-eabi and aarch64-none-elf. > The patches you pointed out before don't even have any effect on the bare > metal ports. The arm and aarch64 bare metal ports are the oddballs in the > group. The difference being: powerpc64-gcc, aarch64-gcc, amd64-gcc, i386-gcc, > mips*-gcc, and sparc64-gcc are all intended for, as you said Mark, alternate > toolchain work with FreeBSD. These are not the official toolchains for > FreeBSD and I can see why they don't have the same level of care as the > official toolchain. But the side effect of this is arm-none-eabi-gcc and > aarch64-none-elf-gcc recei ve the same level of support, though they are *required* to build most FreeBSD systems on those platforms. > > - James Shuriff > > -----Original Message----- > From: Mark Millard <mark...@yahoo.com> > Sent: Sunday, May 19, 2019 11:46 AM > To: James Shuriff <ja...@opentech.cc> > Cc: ports-list freebsd <freebsd-ports@freebsd.org>; b...@freebsd.org; > j...@freebsd.org > Subject: Re: maintenance of gcc cross ports > > > > On 2019-May-19, at 07:40, James Shuriff <james at opentech.cc> wrote: > >> I didn't/don't plan on touching binutils. Binutils is okay. I made new >> patches as well. What I'm really concerned with bringing up to date is >> aarch64-none-elf-gcc. > >> The GNU toolchain is unfortunately required for building an Aarch64 >> system > > Are you specifically referencing contexts that need to build u-boot? (My > guess is: yes.) > > I've done buildworld buildkernel based on system clang and lld many times in > the past, though not very recently. (I currently do not have access to the > environment but will again, eventually.) > > For aarch64 I'd mostly recently built for and used: > > A) a Pine64+ 2GB (needs: sysutils/u-boot-pine64 ) > B) an OverDrive 1000 (no u-boot build needed) > > I've done amd64->aarch64 cross builds and self hosted ones for/on such. The > OverDrive 1000 builds did not involve devel/aarch64-none-elf-gcc at all as > far as I can remember. > >> and is a prereq for a bunch of sysutils arm ports. > > Yep. > > Are there sysutils/u-boot-* 's that no longer build under gcc 6.4.0? > Other things? > >> At worst we can do something like what's done with the lang ports gcc6, >> gcc7, gcc8. I've CC'd the maintainers so hopefully they can give us some >> input and we can come up with a solution. >> >> As for Makefile issues, this is only an issue for the arm-none-eabi-gcc and >> aarch64-none-elf-gcc ports because they have multiple hyphens. It's mostly a >> cosmetic issue. Each port has its own plist because gcc generates different >> headers depending on the platform so the PLIST TARGETARCH regex doesn't >> really affect all that much. There are some clang flags dependent on >> TARGETARCH but whoever wrote the aarch64-none-elf-gcc port must have known >> it wasn't working in the master because the check is in the bare metal port >> as well. The stripping out of all hyphens causes things like "gcc version >> 6.4.0 (FreeBSD Ports Collection for aarch64noneelf)". I use >> ${PKGNAMEPREFIX:C/-$//} for the comment and version and >> ${PKGNAMEPREFIX:C/-.*//} for TARGETARCH. The original regex for all of those >> is ${PKGNAMEPREFIX:C/-//g} and I'm sure you can see how that's a problem >> when there's multiple hyphens. > > Thanks for the notes. > >> - James Shuriff >> >> -----Original Message----- >> From: Mark Millard <mark...@yahoo.com> >> Sent: Sunday, May 19, 2019 1:33 AM >> To: James Shuriff <ja...@opentech.cc>; ports-list freebsd >> <freebsd-ports@freebsd.org> >> Subject: Re: maintenance of gcc cross ports >> >> James Shuriff james at opentech.cc wrote on Sat May 18 12:29:22 UTC 2019 : >> >>> The powerpc64-gcc port and all the ports that use it as a master >>> (aarch64-gcc, aarch64-none-elf-gcc, amd64-gcc, arm-none-eabi-gcc, i386-gcc, >>> mips-gcc, mips64-gcc, and sparc64-gcc) are very old and use buggy >>> makefiles. I would like to take over maintenance of these ports. >>> Powerpc64-gcc uses an old version of gcc and the makefile is buggy. Certain >>> variables use bad regular expressions thus don't do what they're supposed >>> to do. I've fixed up the makefiles and made new plists with a newer version >>> of gcc. >> >> Be aware that: >> >> /[ports]/head/base/binutils depends on devel/binutils via: >> >> MASTERDIR=${.CURDIR}/../../devel/binutils >> >> /[ports]/head/base/gcc depends on devel/powerpc64-gcc via: >> >> EXTRA_PATCHES+= >> ${.CURDIR}/../../devel/powerpc64-gcc/files/freebsd-format-extensions >> EXTRA_PATCHES+= >> ${.CURDIR}/../../devel/powerpc64-gcc/files/freebsd-libdir >> EXTRA_PATCHES+= >> ${.CURDIR}/../../devel/powerpc64-gcc/files/patch-gcc-freebsd-mips >> >> The maintainer is listed as: b...@freebsd.org but the activity tends to be >> j...@freebsd.org . There are other, more overall FreeBSD toolchain efforts >> that these various ports are tied to. That may constrain what can be done >> when. You would probably need to consult with these folks about any changes. >> >> I use these ports for doing alternate toolchain buildworld buildkernel >> activities, including using, say, devel/powerpc64-gcc on a powerpc64 machine >> to self host with more modern tools than gcc 4.2.1 based ones. >> As I understand, being in devel/ instead of lang/ for gcc tools is tied to >> being constructed for the system-building activities instead of for general >> use. >> >> You might want to show your Makefile updates so that that the problems are >> fully explicit. >> > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ________________________________ > DISCLAIMER: This message and any attachments are intended solely for the use > of the recipient and may contain confidential information. If you have > received this message in error please delete it and promptly notify the > sender, James Shuriff (ja...@opentech.cc<mailto:ja...@opentech.cc>). > -- John Baldwin _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
