On 2019-May-21, at 06:56, James Shuriff <james at opentech.cc> wrote:
> What do you think of updating the bare metals to 9.1.0? I don’t know anything > outside of U-Boot and the PSCI Monitor (rpi-firmware) that actually depends > on those ports and I've tested them with my custom ports. The powerpc64-gcc > patches aren't needed to build the bare metal ports. Neither port has listed > maintainers. I am willing to maintain them if no one else wants to. I managed > to get U-Boot to build without GCC but it was a tremendous effort and > required a lot of patches. I've submitted some patches to the U-Boot team but > I don't think they're going to accept them. > > Bug report for regular expression issues is here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237982 FYI: QUOTE svn commit: r502188 - head/lang/gcc9-devel . . . Author: gerald Date: Tue May 21 05:52:16 2019 New Revision: 502188 URL: https://svnweb.freebsd.org/changeset/ports/502188 Log: Update to the 20180518 snapshot of GCC 9.1.1. Proactively add a CONFLICTS statement with the lang/gcc9 port that should be landing any day now. That'll avoid a PORTREVISION bump and rebuild at that point. END QUOTE I do not know if you have been in contact with gerald but he normally covers the lang/gcc* ports. You might end up coordinating with him. > - James Shuriff > > -----Original Message----- > From: John Baldwin <j...@freebsd.org> > Sent: Monday, May 20, 2019 4:45 PM > To: James Shuriff <ja...@opentech.cc>; Mark Millard <mark...@yahoo.com> > Cc: ports-list freebsd <freebsd-ports@freebsd.org>; b...@freebsd.org > Subject: Re: maintenance of gcc cross ports > > 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 receive 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) _______________________________________________ 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"
