Date: Tue, 21 May 2019 09:38:05 -0700 From: Mark Millard <marklmi@yahoo.com> To: James Shuriff <james@opentech.cc> Cc: John Baldwin <jhb@FreeBSD.org>, ports-list freebsd <freebsd-ports@freebsd.org>, "bapt@FreeBSD.org" <bapt@FreeBSD.org>, "gerald@freebsd.org" <gerald@FreeBSD.org> Subject: Re: maintenance of gcc cross ports Message-ID: <39746F66-1794-4EFA-A83B-71D267430F4A@yahoo.com> In-Reply-To: <BN7PR06MB51879E1B52130DCCA11CFF93AA070@BN7PR06MB5187.namprd06.prod.outlook.com> References: <0BDF4BD8-EF07-4226-A2BA-4ACE476CD6FC@yahoo.com> <BN7PR06MB518758AEC18571D655453F05AA050@BN7PR06MB5187.namprd06.prod.outlook.com> <2A90CC78-117B-4988-9022-1687872B6C59@yahoo.com> <BN7PR06MB5187D7636971E006E65D3E2CAA050@BN7PR06MB5187.namprd06.prod.outlook.com> <e3978cb5-0196-0f3f-fa3c-569ad9c91ba7@FreeBSD.org> <BN7PR06MB51879E1B52130DCCA11CFF93AA070@BN7PR06MB5187.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=E2=80=99t = 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. >=20 > Bug report for regular expression issues is here: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237982 FYI: QUOTE svn commit: r502188 - head/lang/gcc9-devel . . . Author: gerald Date: Tue May 21 05:52:16 2019 New Revision: 502188 URL:=20 https://svnweb.freebsd.org/changeset/ports/502188 Log: Update to the 20180518 snapshot of GCC 9.1.1. =20 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 >=20 > -----Original Message----- > From: John Baldwin <jhb@FreeBSD.org> > Sent: Monday, May 20, 2019 4:45 PM > To: James Shuriff <james@opentech.cc>; Mark Millard = <marklmi@yahoo.com> > Cc: ports-list freebsd <freebsd-ports@freebsd.org>; bapt@FreeBSD.org > Subject: Re: maintenance of gcc cross ports >=20 > 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. >=20 > 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): >>=20 >> https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html >>=20 >> Aarch64 is a Tier 2 architecture. The toolchain should have an active = maintainer (the maintainer is listed as ports@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. >>=20 >> - James Shuriff >>=20 >> -----Original Message----- >> From: Mark Millard <marklmi@yahoo.com> >> Sent: Sunday, May 19, 2019 11:46 AM >> To: James Shuriff <james@opentech.cc> >> Cc: ports-list freebsd <freebsd-ports@freebsd.org>; bapt@FreeBSD.org; >> jhb@FreeBSD.org >> Subject: Re: maintenance of gcc cross ports >>=20 >>=20 >>=20 >> On 2019-May-19, at 07:40, James Shuriff <james at opentech.cc> wrote: >>=20 >>> 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. >>=20 >>> The GNU toolchain is unfortunately required for building an Aarch64 >>> system >>=20 >> Are you specifically referencing contexts that need to build u-boot? >> (My guess is: yes.) >>=20 >> 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.) >>=20 >> For aarch64 I'd mostly recently built for and used: >>=20 >> A) a Pine64+ 2GB (needs: sysutils/u-boot-pine64 ) >> B) an OverDrive 1000 (no u-boot build needed) >>=20 >> 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. >>=20 >>> and is a prereq for a bunch of sysutils arm ports. >>=20 >> Yep. >>=20 >> Are there sysutils/u-boot-* 's that no longer build under gcc 6.4.0? >> Other things? >>=20 >>> 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. >>>=20 >>> 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. >>=20 >> Thanks for the notes. >>=20 >>> - James Shuriff >>>=20 >>> -----Original Message----- >>> From: Mark Millard <marklmi@yahoo.com> >>> Sent: Sunday, May 19, 2019 1:33 AM >>> To: James Shuriff <james@opentech.cc>; ports-list freebsd >>> <freebsd-ports@freebsd.org> >>> Subject: Re: maintenance of gcc cross ports >>>=20 >>> James Shuriff james at opentech.cc wrote on Sat May 18 12:29:22 UTC = 2019 : >>>=20 >>>> 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. >>>=20 >>> Be aware that: >>>=20 >>> /[ports]/head/base/binutils depends on devel/binutils via: >>>=20 >>> MASTERDIR=3D${.CURDIR}/../../devel/binutils >>>=20 >>> /[ports]/head/base/gcc depends on devel/powerpc64-gcc via: >>>=20 >>> EXTRA_PATCHES+=3D >>> ${.CURDIR}/../../devel/powerpc64-gcc/files/freebsd-format-extensions >>> EXTRA_PATCHES+=3D >>> ${.CURDIR}/../../devel/powerpc64-gcc/files/freebsd-libdir >>> EXTRA_PATCHES+=3D >>> ${.CURDIR}/../../devel/powerpc64-gcc/files/patch-gcc-freebsd-mips >>>=20 >>> The maintainer is listed as: bapt@FreeBSD.org but the activity tends = to be jhb@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. >>>=20 >>> 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. >>>=20 >>> You might want to show your Makefile updates so that that the = problems are fully explicit. >>>=20 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39746F66-1794-4EFA-A83B-71D267430F4A>