Re: maintenance of gcc cross ports
On 5/21/19 6:56 AM, James Shuriff 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 I don't have an opinion on the bare metal ports, the ones I care about are the -gcc ports used as a FreeBSD toolchain. I would ask bapt@ and/or manu@ what they think about having you maintain the bare metal ports. -- 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"
Re: maintenance of gcc cross ports
On 2019-May-21, at 06:56, James Shuriff 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 > Sent: Monday, May 20, 2019 4:45 PM > To: James Shuriff ; Mark Millard > Cc: ports-list freebsd ; 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 >> Sent: Sunday, May 19, 2019 11:46 AM >> To: James Shuriff >> Cc: ports-list freebsd ; b...@freebsd.org; >> j...@freebsd.org >> Subject: Re: maintenance of gcc cross ports >> >> >> >> On 2019-May-19, at 07:40, James Shuriff 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-b
RE: maintenance of gcc cross ports
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 - James Shuriff -Original Message- From: John Baldwin Sent: Monday, May 20, 2019 4:45 PM To: James Shuriff ; Mark Millard Cc: ports-list freebsd ; 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 > Sent: Sunday, May 19, 2019 11:46 AM > To: James Shuriff > Cc: ports-list freebsd ; b...@freebsd.org; > j...@freebsd.org > Subject: Re: maintenance of gcc cross ports > > > > On 2019-May-19, at 07:40, James Shuriff 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 affec
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 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
> Sent: Sunday, May 19, 2019 11:46 AM
> To: James Shuriff
> Cc: ports-list freebsd ; b...@freebsd.org;
> j...@freebsd.org
> Subject: Re: maintenance of gcc cross ports
>
>
>
> On 2019-May-19, at 07:40, James Shuriff 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
>> Sent: Sunday, May 19, 2019 1:33 AM
>> To: James Shuriff ; ports-list freebsd
RE: maintenance of gcc cross ports
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
Sent: Sunday, May 19, 2019 11:46 AM
To: James Shuriff
Cc: ports-list freebsd ; b...@freebsd.org;
j...@freebsd.org
Subject: Re: maintenance of gcc cross ports
On 2019-May-19, at 07:40, James Shuriff 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
> Sent: Sunday, May 19, 2019 1:33 AM
> To: James Shuriff ; ports-list freebsd
>
> 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
Re: maintenance of gcc cross ports
On 2019-May-19, at 07:40, James Shuriff 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
> Sent: Sunday, May 19, 2019 1:33 AM
> To: James Shuriff ; ports-list freebsd
>
> 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"
RE: maintenance of gcc cross ports
I submitted a bug report. - James Shuriff -Original Message- From: Kurt Jaeger Sent: Sunday, May 19, 2019 3:02 AM To: James Shuriff Cc: freebsd-ports@freebsd.org Subject: Re: maintenance of gcc cross ports Hi! > 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. [...] Can you submit patches via bugs.freebsd.org so that your patches can be worked on ? -- p...@opsec.eu+49 171 3101372One year to go ! 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>). ___ 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"
RE: maintenance of gcc cross ports
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 and is a prereq for a bunch of sysutils arm ports. 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.
- James Shuriff
-Original Message-
From: Mark Millard
Sent: Sunday, May 19, 2019 1:33 AM
To: James Shuriff ; ports-list freebsd
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>).
___
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"
Re: maintenance of gcc cross ports
Hi! > 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. [...] Can you submit patches via bugs.freebsd.org so that your patches can be worked on ? -- p...@opsec.eu+49 171 3101372One year to go ! ___ 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"
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"
