“We’ll turn off -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12).”
This is not ok. It’s a POLA violation since it may break any platform that currently uses base GCC in stable/11 and stable/12. I agree for removal from head but removing it from stable branches is not fine.
What does this mean? 4.2.1 is a very old version of GCC (apparently released in 2007), what purpose did it still serve? Does this have any impact on current GCC versions?
GCC 4.2.1 is still used as the compiler for some tier-2/tier-3 CPU architectures like mips or sparc64. These will need to migrate to Clang, to external GCC from ports, or be removed from the tree.
In addition, I believe the reason they stuck with 4.2 in particular is because it’s the last version of GCC where the whole project is licensed under GPLv2, with the additional restrictions of v3 being considered unacceptable.
(Note in the Android Honeycomb source tree that 4.3 and 4.4 have a COPYING3 which 4.2 does not)
Wait, so you’re gonna make me explain myself? How dare you! ;-P
Just kidding.
Now that llvm is becoming more and more mature, I’d love for the entirety of the OS to be self-hosted with llvm across all supported architectures. FreeBSD has a mechanism for an “external compiler toolchain”–meaning, a compiler toolchain installed via ports/pkg (or otherwise).
FreeBSD will need to continue with the notion of an external toolchain at least until llvm gains support for those architectures where an external toolchain is already required. Regardless of llvm’s architectural support (or lack thereof), having a notion of an external toolchain allows toolchain developers to experiment on the OS from a compiler perspective from outside the actual OS source code tree–especially important for OSes like the BSDs that keep a notion of a basic userland tightly coupled with the kernel.
This is all background info to say: there is really no need for gcc in base, especially given the existing capability to rely on an external toolchain when needed. Therefore: kill gcc with fire.
GCC 4.2.1 is the last gcc under GPLv2, all newer versions are GPLv3. That’s why most BSD’s stayed on 4.2.1 until clang/llvm became the compiler of choice.
I should’ve prefaced my response to say that my beliefs don’t necessarily reflect those of the FreeBSD project’s. From someone on the outside who has been paying attention, it just seems natural to retire gcc 4.2.1 in base in favor of the external toolchain capability.
GCC was good. People did use it. And then Apple poured incredible resources into Clang so they could exert more control over their platform, resulting in Clang becoming a viable alternative to GCC.
I agree, and GCC was also the compiler who has basically killed an industry of crappy proprietary vendor C compilers by supporting C reasonably well and generating code for all kinds of platforms.
That said, the competition from Clang was a very good thing for GCC as well. So in the end, everybody is better off: both GCC for improving due to pressure from Clang and the BSDs for finally having a compiler with a license they like.
The timeline gives powerpc, mips, mips64, and sparc64 9 months to integrate
either into an in-tree compiler, or to have a proven external toolchain
solution. This is on top of the many-years-long warnings about this being
the end game of the clang integration.
Sounds like there is still time and opportunity to keep a few of these architectures going. Folks who care about them apparently need to do a few fixes though.
Did gcc drop support for those in more recent releases? If not, I would think going the external toolchain route (eg. use gcc from ports) would be a faster fix than waiting for upstream support in LLVM.
SPARC has been present in LLVM since 3.x. It’s just a matter of fixing some codegen issues.
That said, FreeBSD/sparc64 has been on life support for years. As much as I hate to say this, it probably should be retired, so people who want to use their SPARCs can migrate to an OS that actually cares about them.
(Hoping that I get time to port musl to sparc64 some time before this 9 months is up…)
FreeBSD’s license is BSD, and prefers BSD like licenses. There is zero issues with ZFS & BSD licensing.
There is a problem with GPLv3 and FreeBSD.
There is arguably an issue with ZFS licensing and the GPL (of any version), but that’s mostly a Linux specific issue and many large companies and organizations disagree about there being a conflict there.
Like tedu says, those are all updated via ports/pkg’s (and generally stay up to date), but are not included in the base OS. FreeBSD is different from Linux. In Linux it’s the kernel only that’s shipped and then Distributions(Debian/Redhat/Ubuntu/etc) add all the GNU stuff, like GCC, rsync, bash, etc and create an OS. Linux by itself is just a kernel, and is not an OS.
FreeBSD ships as a full OS, generally called “base” that is all in 1 VCS tree, that includes the Kernel, libraries, a compiler (clang/LLVM now), a shell, etc, etc. Then it has another VCS tree that is 3rd party software that works with FreeBSD called “ports” and the compiled/binary version of ports is called packages(pkg).
“We’ll turn off -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12).”
This is not ok. It’s a POLA violation since it may break any platform that currently uses base GCC in stable/11 and stable/12. I agree for removal from head but removing it from stable branches is not fine.
In case anyone is lost in the jungle of acronyms:
How would removing
-Werrorbreak things?Code that may build with GCC, but cause warnings may cause runtime errors only when built with GCC.
GCC 4.2.1 hasn’t been the default compiler on tier-1 architectures for years, and is not shipped in any supported release on tier-1 architectures.
In any case I’d suggest following up to the thread on the freebsd-arch mailing list to raise your concern.
What does this mean? 4.2.1 is a very old version of GCC (apparently released in 2007), what purpose did it still serve? Does this have any impact on current GCC versions?
GCC 4.2.1 is still used as the compiler for some tier-2/tier-3 CPU architectures like mips or sparc64. These will need to migrate to Clang, to external GCC from ports, or be removed from the tree.
In addition, I believe the reason they stuck with 4.2 in particular is because it’s the last version of GCC where the whole project is licensed under GPLv2, with the additional restrictions of v3 being considered unacceptable. (Note in the Android Honeycomb source tree that 4.3 and 4.4 have a COPYING3 which 4.2 does not)
Kill it with fire.
Might help to say why.
Wait, so you’re gonna make me explain myself? How dare you! ;-P
Just kidding.
Now that llvm is becoming more and more mature, I’d love for the entirety of the OS to be self-hosted with llvm across all supported architectures. FreeBSD has a mechanism for an “external compiler toolchain”–meaning, a compiler toolchain installed via ports/pkg (or otherwise).
FreeBSD will need to continue with the notion of an external toolchain at least until llvm gains support for those architectures where an external toolchain is already required. Regardless of llvm’s architectural support (or lack thereof), having a notion of an external toolchain allows toolchain developers to experiment on the OS from a compiler perspective from outside the actual OS source code tree–especially important for OSes like the BSDs that keep a notion of a basic userland tightly coupled with the kernel.
This is all background info to say: there is really no need for gcc in base, especially given the existing capability to rely on an external toolchain when needed. Therefore: kill gcc with fire.
Basically GCC is fine, GCC 4.2.1 that’s been obsolete for a decade isn’t.
GCC 4.2.1 is the last gcc under GPLv2, all newer versions are GPLv3. That’s why most BSD’s stayed on 4.2.1 until clang/llvm became the compiler of choice.
I should’ve prefaced my response to say that my beliefs don’t necessarily reflect those of the FreeBSD project’s. From someone on the outside who has been paying attention, it just seems natural to retire gcc 4.2.1 in base in favor of the external toolchain capability.
No worries, just adding a bit of clarification.
So, anyone want to speculate how GPL lost the mindshare war here?
If GCC were good, people would use it. And GPL would have a foothold.
Clang being BSD = major blow to GPL.
BSD people like to use software with BSD licenses?
GCC was good. People did use it. And then Apple poured incredible resources into Clang so they could exert more control over their platform, resulting in Clang becoming a viable alternative to GCC.
I agree, and GCC was also the compiler who has basically killed an industry of crappy proprietary vendor C compilers by supporting C reasonably well and generating code for all kinds of platforms.
That said, the competition from Clang was a very good thing for GCC as well. So in the end, everybody is better off: both GCC for improving due to pressure from Clang and the BSDs for finally having a compiler with a license they like.
So FreeBSD is de-facto dropping a bunch of architectures?
From the email:
Sounds like there is still time and opportunity to keep a few of these architectures going. Folks who care about them apparently need to do a few fixes though.
Cool, so yes. I can’t imagine mips32, sparc etc landing in LLVM quickly. I guess this will push back RISC-V support too.
sparc64 almost seems to work in openbsd with a few patches.
Did gcc drop support for those in more recent releases? If not, I would think going the external toolchain route (eg. use gcc from ports) would be a faster fix than waiting for upstream support in LLVM.
SPARC has been present in LLVM since 3.x. It’s just a matter of fixing some codegen issues.
That said, FreeBSD/sparc64 has been on life support for years. As much as I hate to say this, it probably should be retired, so people who want to use their SPARCs can migrate to an OS that actually cares about them.
(Hoping that I get time to port musl to sparc64 some time before this 9 months is up…)
powerpc, powerpc64 and powerpcspe plan to switch to LLVM once LLVM 9.0 is released.
Per https://lists.freebsd.org/pipermail/freebsd-arch/2019-August/019679.html, it looks like mips64 will also migrate.
What’s the reason for this? If they’re concerned about the license are they looking to replace ZFS too?
GCC 4.2.1 is ancient. Current version is 9.2
FreeBSD’s license is BSD, and prefers BSD like licenses. There is zero issues with ZFS & BSD licensing.
There is a problem with GPLv3 and FreeBSD.
There is arguably an issue with ZFS licensing and the GPL (of any version), but that’s mostly a Linux specific issue and many large companies and organizations disagree about there being a conflict there.
So does FreeBSD ship ancient known-insecure versions of other GPL software or do they drop rsync, bash, etc?
Like tedu says, those are all updated via ports/pkg’s (and generally stay up to date), but are not included in the base OS. FreeBSD is different from Linux. In Linux it’s the kernel only that’s shipped and then Distributions(Debian/Redhat/Ubuntu/etc) add all the GNU stuff, like GCC, rsync, bash, etc and create an OS. Linux by itself is just a kernel, and is not an OS.
FreeBSD ships as a full OS, generally called “base” that is all in 1 VCS tree, that includes the Kernel, libraries, a compiler (clang/LLVM now), a shell, etc, etc. Then it has another VCS tree that is 3rd party software that works with FreeBSD called “ports” and the compiled/binary version of ports is called packages(pkg).
None of those are included in base.