Skip site navigation (1)Skip section navigation (2)
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>