[bcaa7f3a8bbc]

The title is highly misleading. First, it's the ancient GCC 4.2.1 from 2007. Next, it's removed from the FreeBSD build system, which means it's no longer used in the internal development of FreeBSD and you can no longer build FreeBSD with GCC. Meanwhile, GCC is still maintained for userspace and the latest GCC 9 is included in the FreeBSD Port [0], you can install it on your machine for your personal use. Finally, the commit message said "At this time all supported architectures either use in-tree Clang, or rely on external toolchain (i.e., a contemporary GCC version from ports)", so I assume even with GCC support removed, you can still build FreeBSD, if you insist, with an external copy of modern GCC.

Suggested alternative title: FreeBSD has Removed GCC from Build Infrastructure.

[0] https://github.com/freebsd/freebsd-ports/blob/master/Mk/bsd....

[gcoleman]

OP here. I assumed knowledge of how FreeBSD works and the ongoing efforts to move to clang. I can see how the title could be misleading for people who are not familiar.

As others have pointed out "FreeBSD has removed GCC from the. base system" would be a better title.

[cryptonector]

The damned version number should be in the title.

[dang]

That would imply that a different version might be left in.

[simias]

I disagree, for anybody who knows how FreeBSD works the title is perfectly clear IMO. They removed FreeBSD from the base system. Of course you can still build GCC from ports, but that's not part of the base OS.

It's as if MacOS decided to stop shipping bash by default. Of course you'll still be able to install it yourself, but it's not part of the OS anymore and you can't rely on it being available and supported.

FreeBSD is not Linux, it's a full OS, not just a kernel. There's a very clear line between what's part of the base system and what's not.

[ori_b]

> I disagree, for anybody who knows how FreeBSD works

That excludes the bulk of this site's readers.

[kazinator]

People are here obtusely misunderstanding more than just how FreeBSD works.

Imagine this:

"Microsoft has removed Notepad from Windows!"

"You dummy, no it hasn't; you can still get a Notepad for Windows from the Microsoft Store! Microsoft only removed it from the base installation of Windows, not from Windows as such."

Doh? If that happened, you would no longer be able to rely on any installation of Windows to have Notepad.

[simias]

Perhaps, but then the distinction between the base system and ports will be lost on them too, and saying that it's merely been removed from the build system doesn't do this news justice IMO, it's more significant than that.

Maybe we could compromise with "FreeBSD has removed GCC from its base system" or something similar.

[amyjess]

> Maybe we could compromise with "FreeBSD has removed GCC from its base system" or something similar.

I think this would make the best headline.

[JdeBP]

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize. (https://news.ycombinator.com/newsguidelines.html)

Which would make the headline that is most in accordance with the guidelines here:

"remove GCC 4.2.1 build infrastructure"

[JdeBP]

The thing is that it is not significant news, except perhaps to FreeBSD base developers. It does not signify anything really, certainly not all of the things that people are reading into it even in this very discussion. It's not the death knell of GCC. It's not some sort of war. It has no impact on FreeBSD users, or on people building applications on FreeBSD. It's not even much of a change, considering that the actual concrete change, switching compilers, happened a while ago.

[MaxBarraclough]

> The thing is that it is not significant news, except perhaps to FreeBSD base developers

I think it's significant news, and I have no connection to FreeBSD. It's a significant milestone for Clang, which makes it significant news to C programmers.

> It's not some sort of war.

Well, these compilers are competing with each other. It's a bit like the browser war, such as it is. If there were a respectable BSD-licensed browser, I'm sure the various FreeBSD-on-desktop distros would favour it.

> It's not even much of a change, considering that the actual concrete change, switching compilers, happened a while ago.

As a nail in the coffin moment I'd say it's still significant.

[oefrha]

It’s a good time for the bulk of this site’s readers to learn something about the BSD philosophy then.

Edit: This comment was not meant to be snarky.

[BanazirGalbasi]

I'm a relatively new FreeBSD user, in fact I'm writing this on a Thinkpad running FreeBSD right now. The title is still super misleading, I had no clue that it was talking about the build infrastructure from the title alone - instead, I was expecting that my next version upgrade would remove GCC compatibility. Learning the FreeBSD philosophy doesn't change the fact that the title is inaccurate and unhelpful.

[umanwizard]

Yes, your next upgrade will remove GCC from the base system, not just from the "build infrastructure". However, you can still install the GCC port, as before.

[kevans91]

With a tiny caveat: most folks actually won't feel this, because GCC hasn't been included in any x86 installed base system for quite a while now. Most exposure to it for many users would have been if they were cross-building archs that still required it, as the build infrastructure would bootstrap an appropriate GCC4.2 at that time.

[BanazirGalbasi]

I think you misunderstood what I was saying - I was expecting that this post would mean that GCC would stop working, or no longer be available, for me as a user. The point is that even for a FreeBSD user - albeit a new one - the title here is unclear on what "removed GCC" means.

[chrisseaton]

You can't expect people to be experts in everything.

[oefrha]

I didn’t expect people to be experts in everything, and my comment says the exact opposite: non-experts could learn a little bit about the subject.

[degski]

I just learned something useful! There might be more crud in BSD, better avoid. The fact they only now remove gcc-4.2 as the base of their system has told me more than enough, thanks, but no thanks.

[lvh]

The title does not say "FreeBSD has removed GCC from the base system". It says "FreeBSD has removed GCC", full stop. Ports are also managed by the FreeBSD project, as I'm sure you'll agree.

[cat199]

But 'FreeBSD Ports' are not 'FreeBSD' itself.

Title was clear to me - yes, perhaps more clear as you say it though.

[lvh]

I've ran every major BSD as a desktop OS and my first read was "what?! I knew Clang was getting good at pretending to be GCC nowadays but there's no way they've thrown it out of ports, right?!". And indeed, they haven't, but not because I read the title correctly.

[twic]

The title very evidently wasn't clear to the casual reader. Today, you learned something!

[lloeki]

> It's as if MacOS decided to stop shipping bash by default.

More precisely, it’s as if macOS stopped shipping GCC in the CLT.

Oh wait, they did exactly that already, the last one being gcc 4.2 on Darwin 11, after that a GCC command is still present but it’s just a front to llvm.

https://github.com/archmac/packages/blob/master/core/apple-g...

[fullstop]

> It's as if MacOS decided to stop shipping bash by default.

They switched from tcsh to bash, so it's not out of the question.

edit: looks like tcsh is still available, but not the default.

[michaelsbradley]

https://support.apple.com/en-us/HT208050

[derefr]

> and you can’t rely on it being available and supported

Is there a reason that you’d be relying on what’s included in the FreeBSD base system? If I were building a piece of software and developing a FreeBSD target for it, I’d probably just write a port manifest for it and contribute it; and in so doing, I can have my port manifest declare a dependency on the GCC port.

Just like if I create an Ubuntu PPA, I can depend on Ubuntu system packages, or even other people’s PPAs. (And it’s even less arduous than the Ubuntu PPA case, because PPAs are all their own third-party package repos that you have to add, while Ports is one flat namespace. As long as it’s “in ports”, you can depend on it without asking the user to do the equivalent of `sudo apt-repository add ...`)

[pjmlp]

IT security where you just get what they think you should be using, and regular accounts don't have execution permissions on any user accessible file system.

[derefr]

Presumably we're talking, here, about relying on GCC as part of the build-process of a package or script you're trying to deploy to this system.

If you don't have execute permissions, then, well, you're not going to be "installing" any software in any practical sense—you might be able to compile sources or copy files around, but you can't make the resulting binaries executable. Nor are you going to be doing much software development, for the same reason.

So why, at that point, would you need a compiler to exist on the box? It'd be like having GCC in a busybox installation.

[pjmlp]

Yes you will be doing software development, but only for what matters to your employer and nothing else.

Savy UNIX IT can take care of it, apparently the experience of what meant working in UNIX shops with thin terminals is now lost.

[pankajdoharey]

Though i dont know how FreeBSD works after reading the title my first guess was hah, so are they completely switching to clang or some other compiler. But i think maybe if the title read "FreeBSD would stop GCC support" or something would have made it more clear on the outset, may be thats what the he is referring to.

[umanwizard]

> so are they completely switching to clang or some other compiler.

Yes, they are -- your understanding was correct. The FreeBSD OS now exclusively builds with clang, and clang is also the compiler shipped with the system.

You can, of course, still install GCC, and many other packages, from the ports tree, but it is no longer part of the OS.

[emaste]

In fact for the vast majority of FreeBSD users (those on i386 or amd64), this happened years ago. Old GCC was kept in the tree for some Tier-2/Tier-3 archs (like MIPS), and is now removed because it's no longer used for those.

[m463]

MacOS is moving to zsh (I think they still ship bash)

[wolfhumble]

macOS Catalina, i.e. version 10.15, has actually already moved to zsh, but – as you said – bash is still installed:

% bash -version

=> GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)

[tbenst]

I ran FreeBSD for years, and this title still surprised me. I thought it was gone from ports too for ____ reason. Misleading

[kevans91]

> [...] so I assume even with GCC support removed, you can still build FreeBSD, if you insist, with an external copy of modern GCC.

Indeed- "external toolchain" includes gcc6[0] and gcc9[1] ports that can be used specifically for building the FreeBSD base system. These are mostly easy to use, install the flavor for whatever architecture you're building and specify CROSS_TOOLCHAIN=<arch>-gcc6 when you build. More/better/complete information (and examples!) at [2].

[0] https://www.freshports.org/devel/freebsd-gcc6

[1] https://www.freshports.org/devel/freebsd-gcc9

[2] https://wiki.freebsd.org/ExternalToolchain

[grapeli23]

What compiler is used to build blas and lapack, as well as a whole lot of programming based on them like numpy, scipy, julia, etc.?

[loeg]

That's encoded in each individual port.

lapack, for example, has USES=fortran[1]. That invokes Uses/fortran.mk[2] and accepts the ports-default fortran compiler, FORTRAN_DEFAULT, which is definedin bsd.default-versions.mk[3] as gfortran (GCC).

[1]: https://svnweb.freebsd.org/ports/head/math/lapack/Makefile?r...

[2]: https://svnweb.freebsd.org/ports/head/Mk/Uses/fortran.mk?rev...

[3]: https://svnweb.freebsd.org/ports/head/Mk/bsd.default-version...

[kevans91]

Nothing changes here- this is solely about removing GCC 4.2 from the base/ repository; ports are almost entirely unaffected, and the GCC ecosystem in ports is fairly healthy.

[dang]

Ok, we've put the base system in the title above.

[umanwizard]

It was entirely removed from the operating system. As with most general-purpose operating systems, nothing prevents FreeBSD users from installing third-party software, including GCC. This does not mean that GCC is still part of the OS.

[agapon]

There are many ways to install third-party software. Some are harder: download source and build from it yourself (while handling any cross-platform issues, etc). Some are easier: just install from an OS supplied package. The latter still works for GCC on FreeBSD.

[umanwizard]

It is a ports tree provided package, not an OS supplied package. Ports are not considered part of the OS.

[agapon]

I'd argue that the software provided via the ports is not part of the OS. But the FreeBSD ports themselves (and official packages built from them) can be considered part of FreeBSD.

P.S. You can disagree with me and state your point, but you do not have to downvote me.

[umanwizard]

I didn't downvote you: https://i.imgur.com/PPNWIqA.png

[loeg]

I don't know what to tell you. As someone who develops and uses FreeBSD, the title is true on its face and long-awaited. Yes, "from the base system as a supported base compiler" is implicit context here that someone outside of that community might not understand, but I think everyone familiar with FreeBSD can understand the headline, or failing that, the body of the (short) commit message and have a good understanding of the truth.

[ianai]

Is it all licensing making the push away from gcc?

[lvh]

Depends on how you look at it. It's that particular old version of GCC in base because of licensing, yes -- but that old version is now effectively obsolete, so there's a technical reason (originally forced from licensing) to move away from it.

That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_. Clang showed up with colorized error messages and ASCII art arrows and it felt like magic. So, sure, licensing alone would have been a fine reason for base to do what it did, but I don't think it's fair to characterize it as _just_ licensing. GCC has made huge improvements since then, but those are only visible in ports (which has always had and continues to have modern GCC). Which I guess you could argue makes it a licensing issue? :-)

[JdeBP]

I've recently found something to dislike about the coloured error messages.

The default colour is restored after the newline, rather than before it.

* https://github.com/llvm-mirror/clang/blob/6803cc1958b56e0bd5...

I have recently set DECSCNM on in my terminal(s), which inverts everything, effectively swapping the foreground and background colours. The clang error messages now come out with unsightly large streaks of extraneous colour, as freshly erased lines caused by scrolling fill with the colour that clang has not yet turned off. clang was always doing this. But when it's the background colour it's more visible.

It would be such a simple fix, that's actually in line with code elsewhere in the same class. I wonder how many years it will take to get it changed.

[clarry]

> That said: it's good to remember how much of a breath of fresh air clang was way back when. Error messages in that era of GCC were _terrible_.

I disagree; I think clang set a trend and now GCC's error message are worse than they used to be. In the recent days I've seriously considered patching them out because I'm getting really tired of the wall of text of useless suggestions, macro expansion, etc. that hides the actual error. 99% of the time I just need to see which line my error originates from (before any macro expansion) and I can follow the chain manually in the remaining 1% of cases.

What's happening now is that I have a line with an error, and I get 50 lines of trash output among which the actual error is buried. And trying to jump to the error in my editor has me jump through headers, #include rows, and other garbage, sometimes missing the original error line entirely!

It's ridiculous. The suggestions are also largely either wrong or so obvious that they have only negative value. It's just clutter. Same goes for the ascii art arrows. Just clutter, making it harder to see relevant things.

I can see these messages being helpful for a total newbie who's still acquainting themselves with the standard library and figuring out the basics of the language, but for me (writing C daily for a living, and as a hobby for the past 15+ years) it's just getting in the way.

[dman]

Perhaps users should be given a mechanism for configuring the error printing :)

[Avamander]

I can't help but be reminded of https://xkcd.com/1172/

[JdeBP]

It's a pity that you weren't instead reminded of -fno-color-diagnostics, -fno-caret-diagnostics, and -fno-diagnostics-show-note-include-stack. You could have told clarry about them. (-:

[loeg]

IMO, still very much a licensing issue. Modern GPL3 GCC versions produce superior debuginfo as compared with Clang, in 2020, and the error messages and optimizations are currently competitive between the two. The ancient GPL2 GCC4.2.1 (C) compiled much faster than the modern Clang (C++), but I don't know if that still holds true for newer versions of GCC.

I have heard that the LLD (LLVM linker) is much faster than either ld.bfd or ld.gold.

[guenthert]

In which way terrible? Error messages for C++ were at times unhelpful, but I can't remember being dissatisfied with those for C. Outside the Desktop environment, is there much C++ code in the FreeBSD system?

[JdeBP]

devd is C++, and it is not alone. Unfortunately, the dynamically-linkable C++ runtime library is in the wrong place, and not in the same place as the C runtime library, so things like devd have to be statically linked.

But the clang switch was not motivated by its C++ error messages, to my knowledge.

[lvh]

I was making a general comment about clang vs gcc: the push to clang was not exclusive to FreeBSD.

[ethelward]

IIRC, yes; it was the last version under GPLv2.

[alerighi]

What is the problem of using a GPLv3 compiler? Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem.

Not only that, but even proprietary software can be built with a GPL compiler, the binaries produced by the compiler are not considered derived work that must be covered by the same GPL license, so if Microsoft wanst to build Windows with GCC for example they can do that, provided that they don't link in the executable produced GPL code (e.g. glibc).

[lazyier]

The legal subject of licensing GPLv3 is a lot more nuanced then you are indicating. One example of this is that while the license can explicitly allow proprietary software to link to a library it cannot explicitly deny proprietary software linking to a library. Copyright law defines what is and what isn't derivative works, not licenses. And copyright licenses are fundamentally limited to copyright law.

But there are technical reasons to avoid using GCC nowadays as well.

The GNU people have built in shitty anti-features into GCC suite, ostensibly to limit the ability of proprietary software to incorporate GCC into their products.

LLVM, which is what CLang uses, was partially a response to the artificial technical limitations intentionally imposed on users by the GNU GCC authors.

[nrclark]

The main issue with GPLv3 software isn't the linking. You can link stuff using GCC without making sources available to anybody.

The main issue with GPLv3 is the so-called Tivoization clause. It basically states that if you have a product that ships with any GPLv3 software, you need to give your users the ability to install a modified version of anything you included that's GPLv3. Which basically means you can't lock down your device. That's a big security risk on an embedded system - both from an IP protection point of view, and also from a botnet/pwning point of view.

FreeBSD (and others presumably) don't want their users to need to worry about accidentally installing something from the core system and finding themselves in violation of the GPL.

[cycloptic]

>That's a big security risk on an embedded system - both from an IP protection point of view

If a company is interested in "protecting their IP" by closing the source then it's questionable why they would have even wanted to use GPLv2 software at all. The OEM's IP situation is also not related to the security of the customer. Maybe it matters to the security of the OEM, but that's different.

>and also from a botnet/pwning point of view

Complying with the GPLv3 doesn't mean the device becomes vulnerable to botnets. All it means is that the customer who purchased the device has to get access to the hardware keys. For their own device. That they purchased.

[belorn]

When ever people mention the Tivoization clause they forget to include the big exception which the license gives. You do not need to give your users the ability to install a modified version of GPLv3 software if there is no mechanism for which the manufacturer can modify the software after sale.

People can create any number of embedded system which are locked down so no one can change the software. The key here is nobody. Not the user, not the manufacturer, not some backdooring third party.

People are free to argue that allowing manufacturers access to devices after sale but not the actually owners is a security feature to prevent botnets and pwning, but that is a harder sell.

[kick]

That's a bit revisionist in every sense.

https://gcc.gnu.org/ml/gcc/2005-11/msg00888.html

[Avamander]

I don't see it as an anti-feature.

[cycloptic]

Don't write proprietary compilers. You can thank GCC for mostly eliminating that possibility in the years before clang. Now we are dealing with that again.

[throw0101a]

> Only political reason, since FreeBSD is still an open source project and they can use GPLv3 software without any problem.

And what about Dell EMC Isilon OneFS, which uses FreeBSD as the base of their product? Or Panasas or NetApp? Juniper? Sony and their PlayStation 4? Netflix?

* https://en.wikipedia.org/wiki/List_of_products_based_on_Free...

FreeBSD is not just looking at themselves, but also at their users, which my have issues with GPLv3.