FreeBSD has removed GCC from its base system | Hacker News Reader

FreeBSD has removed GCC from its base system

github.com

287 pointsgcoleman176 comments

Point of order: removed GCC /from the base system/. Ports still have a range of GCCs and some ports still depend on GCC. The GCC in base was well over a decade old, and it was that particular version for the same reason macOS shipped an ancient version of bash for a decade: it was the last one licensed under GPLv2.

This is effectively an administrative change. (Not to downplay the work!)

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....

Is it all licensing making the push away from gcc?

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

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).

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.

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

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.

That's a bit revisionist in every sense.

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

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.

>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.

> 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. That also is not related to the security of the customer at all. Maybe it matters to the security of the OEM, but that's different.

I can't speak for other engineers. But at companies I've worked in, a common product model is "embedded Linux with GPLv2 software, and some proprietary secret-sauce binaries". At those companies, they usually do send patches to upstream open-source projects and they try to contribute. Also they usually provide full source-code on request, for everything except the proprietary stuff.

The net effect of GPLv3 has been that GNU packages basically don't exist on embedded devices any more. Which means that engineers like me don't have the professional opportunity to contribute features and patches. It sort of isolates GPLv3 projects into a walled garden, which I feel like is the opposite of what GPL was intended to foster. Instead, I can only have the professional opportunity to contribute on GPLv2 or permissive-license projects.

> 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.

I sympathize with the intent behind this. There are also just some practical realities that are tough. At my current company, the team working on our next embedded Linux product is pretty small. We don't have infinite time or resources to make sure that our own code is 100% intrusion-resistant - all we can do is try our best.

It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead.

And if you have access to the filesystem, it's that much easier to comb through it and look for vulnerabilities in our network updater (for example). And it's easier to pick apart the proprietary bits with Ghidra or something. Could you do it anyways, even without our help? Maybe. But it's much harder.

Can we design a system that's robust enough to allow you to install whatever you want on your unit? Maybe. Probably. Hopefully we're already there. But I'm not going to risk my company's livelihood on it just to ship GPLv3 software, especially considering that there are almost-as-good alternatives for a lot of it. We just don't have the resources to make sure we cover every security angle on an open-box system.

We are in a bind here. If you ship GPLv2 software on a locked down device then nobody downstream has the professional opportunity to contribute, because they simply can't get any of their changes onto the device. The reason to rectify this is not "to ship GPLv3 software" the reason is because otherwise customers don't have control over their own devices.

The developers who relicensed to GPLv3 don't care that some companies won't contribute. From their perspective, any of those contributions would be unusable to them. I feel a similar way with my open source projects -- why would I as an outsider maintain code that nobody outside of your company will ever have any possible way to test in a real production scenario? It's a waste of my time. Yes I might be missing out on minor bug-fixes but I don't really care about that. Like you said, feature development is more important.

As far as firmware-updating goes, to be in compliance the user just needs to have some way to get access to the keys. You don't need to make separate keys, it can be the same method that you use.

> We are in a bind here. If you ship GPLv2 software on a locked down device then nobody downstream has the professional opportunity to contribute, because they simply can't get any of their changes onto the device.

I should clarify - what I meant is that if we're shipping GPLv2 software like Busybox, then I'm able to spend billable time improving Busybox and upstreaming my patches. That's labor that could be going to GNU coreutils instead, if it was the userspace on my product. But since I'm not shipping it, that means I don't find bugs or need features very often. Which means I have way less of an opportunity to pitch in.

That's great for you. In that situation, if my company buys your product, we have zero opportunity to pitch in to Busybox and are not able to spend any of our billable time upstreaming our patches, because the device is locked down. Who wins here? It's not the project who wins, because they lost contributions. It's not my company or any of your other customers who win, because we can't contribute. It's not you who wins, because if you get a different job then you lose access to the device and can't contribute, and you also lose the billable consulting hours that you could have charged to my company. It's not your company who wins, because they lose the shared contributions from my company.

I'm not making this up either. Even in my personal life I own lots of random devices that I know for a fact are running Linux and Busybox. But I have to go out of my way to find a device that I actually have a chance to get a toolchain running on and can actually start working on patches. It's usually limited to old devices that had no security or had their security broken. So any contributions I make are limited to things that only work on insecure old legacy hardware, stuff that is not going to be of interest to your company working on the next new hotness. There is a real problem here that's in-part solved by the GPLv3, but you have to actually acknowledge that it's a problem.

Just a note - I appreciate this discussion, and your point of view! Thanks for having it.

Ease of contribution is a problem for sure, and it's one that GPLv3 was intended to address. My main point is that the changes from GPLv2 actually had the opposite effect for a whole group of developers.

Instead of encouraging -more- development, I feel like maybe it's just driven developers away and onto GPLv2, MIT, or BSD equivalents. Maybe this is intended behavior, and not an accidental side-effect. I don't know. But it's hard to dispute that it reduces the pool of potential contributors to GPLv3 packages.

GPLv3 components just aren't an option for a lot of products, regardless of whether GPLv3 is better for users (I agree that it is). I think it's really harmed the FSF a lot. With fewer installations of FSF packages, the FSF sees less participation and loses some of its clout. And that makes me sad :(

People and groups that wanted to contribute but couldn't because of locked-down devices were already driven away and discouraged from development. And it was worse for them, if you own a locked-down device you can't go and decide to run FreeBSD on it to fix that. You just can't work on it at all. The GPLv3 was drafted in response to complaints about this -- specifically, companies that were shipping Linux and Busybox and were either straight-up GPL violating, or were telling users to get lost when they asked how it would be possible to get patched software on the device in any practical sense. From my perspective, there already was a wall in between those companies locking down their devices and the rest of the community. The GPLv3 only highlighted it.

> It's a big ask for us to support _two_ methods of firmware-update (local and over-the-network) with different keys/security requirements for each. We just plain don't have the manpower to support that, not when we can be developing features to improve our product instead.

But you don't have to do two different systems. You can use the exact same update mechanism, just with the cryptographic validation controlled by the owner of the hardware.

Look at how Secure Boot is implemented on most x86 platforms. Default installed keys from the OEM, can not be changed from the OS, but can be disabled or replaced by the end user.

Chromebooks offer another example of how to do it well with their "Developer Mode" switches. With the switch (which is not accessible on an operating system) in the default position it will only boot Google signed images. With the switch in developer mode it notifies the user of this on every boot, but no longer verifies signatures. The device is factory reset when switching modes to ensure that the unsigned mode can not be used to compromise a stolen device.

Android phones with unlockable bootloaders work similarly, they just have a software toggle in the first-stage bootloader rather than a physical switch.

---

There are plenty of low-effort ways to provide cryptographic verifiability to end users while still following not just the letter but the spirit of the GPL.

Obviously most of us would prefer something like the first example where a user could replace the stock keys with their own and sign their own code to maintain full security when going off on their own, the second and third options are nearly trivial to implement. One switch or jumper, a single input pin, and however much code it takes to check the state of that pin when performing any boot validation.

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.

> 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.

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? :-)

> 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.

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

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

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. (-:

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?

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

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.

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.

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.

> [...] 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

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.?

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...

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.

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.

> 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...

> 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.

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

> I disagree, for anybody who knows how FreeBSD works

That excludes the bulk of this site's readers.

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.

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

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.

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.

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.

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.

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.

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.

But FreeBSD doesn’t control what software works on FreeBSD, that is up to the individual software maintainers. What you are describing would be “GCC has removed support for FreeBSD.”

Then you really need to read up handbook again. Removing things from base never meant what you think it meant.

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.

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

I think this would make the best headline.

> 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"

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.

> 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.

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.

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.

> 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.

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.

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.

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

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

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

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.

> 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 ...`)

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.

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.

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.

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

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

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)

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.

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.

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

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.

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

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.

The damned version number should be in the title.

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

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.

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

I don't know the whole space well, but there are posts about FreeBSD and IBM today moving to clang.

Is there some tipping point where gcc has too few significant end users to stay relevant? I'd hate to lose the diversity.

It's unlikely as up until now it was the only compiler capable of building the Linux kernel (due to its reliance on some GCC extensions to the language).

It is primarily non-GPL platforms/systems/companies that are switching to clang for it's much friendlier license.

Edit: "~now" rather than "now"

That's part of why I ask. As of late last year, clang can compile x86_64 Linux 5.x kernels.

Building the kernel with clang has been possible or a while. https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNote...:

"With support for asm goto, the mainline Linux kernel for x86_64 is now buildable (and bootable) with Clang 9. Other architectures that don’t require CONFIG_JUMP_LABEL=y such as arm, aarch64, ppc32, ppc64le, (and possibly mips) have been supported with older releases of Clang (Clang 4 was first used with aarch64).

The Android and ChromeOS Linux distributions have moved to building their Linux kernels with Clang, and Google is currently testing Clang built kernels for their production Linux kernels."

That was in September 2019

Yes, I consider within the past year to qualify as "now," but I've updated my post :)

Within the past year is more nuanced. Clang was building working kernels since clang-4. X86 developers decided to require asm goto around Linux 4.20, which regressed clang builds for one architecture, until clang-9 implemented it. You could still build LTS kernels without asm goto.

Clang can't compile glibc which actually a bigger problem.

In my opinion it's also time to move on from glibc.

Without clang we would still have terrible compile error messages.

As clang implements more and more of GCC's extensions, though, I could see things reaching that tipping point.

And without a GPL compiler, we will be back to the PD and *ware days.

Sony, Apple, IBM, and plenty of other embedded vendors don't contribute 100% their improvements back to LLVM.

Apple does like 80% of the open source development of LLVM; I don't really see a valid angle to criticize their participation in LLVM at this time.

Except that they happen to have an actual portable variant of bitcode for watchOS, their clang implementation different enough from mainline clang to warrant its own column on cppreference compiler listing, and Objective-C and Swift related changes are on "just what you need to know" basis and the community should put the missing pieces.

Personally I don't care, as I am mostly a commercial software user nowadays.

Just making the point that LLVM victory over GCC, might not turn out as FOSS supporters expect.

Apple Clang gets its own column because it doesn't align with the official LLVM release schedule, which is also why it doesn't use the upstream version numbers.

That does not make sense. They could simply use the LLVM version, even if it was an old one.

I just implemented a GNU C extension in Clang today! `asm inline`

FreeBSD has been using Clang as the default build system for x86/64 since.. 2012? Version 10.0 IIRC. Not sure about mips, sparc, power but think they moved previously as well?

powerpc64 switched over in late December; sparc64 never made the switch (unfortunately), and mips will make the switch with the introduction of llvm 10.

IIRC powerpc32 is currently using clang with old bfd ld, but lld in llvm 10 may be quickly reaching the point where it's suitable for powerpc32 as well.

> sparc64 never made the switch (unfortunately)

Care to elaborate?

We're maintaining sparc64 in Debian Ports and we have smashed quite a number of bugs in the SPARC backend in LLVM.

Are there any issues you are seeing?

This is specifically w.r.t. FreeBSD -- nobody put in the effort to maintain it, so it's removed in head/ as of now. As far as I'm aware, no one had tested sparc64/llvm on FreeBSD either.

I see, thanks. I know the NetBSD guys are still working on their sparc64 port.

10.0, 2014 for amd64/i386. Much later for MIPS and Power (within the last year). Sparc was deorbited as part of the GCC4.2.1 retirement effort — no one showed up to implement Sparc support in Clang, and the version of Sparc hardware FreeBSD ran on was extremely obsolete anyway.

> Sparc was deorbited as part of the GCC4.2.1 retirement effort — no one showed up to implement Sparc support in Clang, and the version of Sparc hardware FreeBSD ran on was extremely obsolete anyway.

What's missing for sparc64 in Clang? We have Clang on sparc64 in Debian Ports.

> What's missing for sparc64 in Clang?

My memory here is fuzzy because I'm very much not interested in Sparc, but, as far as technical shortcomings: there are integrated-assembler (ias) pieces missing; ld.lld support is extremely incomplete; it's missing a working stack unwinder. If you look for Sparc work in Clang upstream, it becomes obvious that it's not active.

The biggest thing missing was interest (and associated time and resources). People have had 6-12 months to step up if they wanted to work on moving platforms off of GCC4.2.1, and unlike for every other tier 2-3 arch formerly on GCC, no one showed up to work on Sparc.

> We have Clang on sparc64 in Debian Ports.

As in you can compile Clang on sparc (using GCC / binutils as the system compiler), or as in you can actually build Debian for sparc64 using Clang?

Here's some more context around missing pieces:

https://svnweb.freebsd.org/base?view=revision&revision=35446...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233405

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236839

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239851

> As in you can compile Clang on sparc (using GCC / binutils as the system compiler), or as in you can actually build Debian for sparc64 using Clang?

Initially, we were building Clang only. But we're also now building Clang using itself, i.e. a stage2 compiler.

There are issues though when building Clang with Clang with Gold as the linker. It works fine with BFD though.

We are not building the whole archive with Clang though. But all Rust packages are built on sparc64 as well which uses the LLVM backend.

Thanks for the links. I'll look into them. Maybe we find some more bugs than can be fixed on SPARC in LLVM/Clang.

Edit: From your first link:

> "Contemporary GCC does not build and there is currently no indication that anyone is going to address these issues."

That's odd. We're building all GCC versions on Debian/sparc64. It's still a maintained backend in GCC, after all.

We used to celebrate alternatives to gcc in the name of compiler diversity, and now we're wondering about gcc preservation in the name of compiler diversity.

This is mostly just an observation, I'm not sure how I feel about it. Compiler diversity doesn't seem more important than OS diversity to me, and none of these feel particularly important. As a user I was happy to switch to clang for the better error messages.

As other top-level posts have pointed out they're only removing it from the build process, it's still available to users. I wouldn't worry too much about about GCC going away, it's still the default compiler for most (all?) Linux distros.

It was removed from the operating system. As with most operating systems, nothing prevents users from installing third-party software including GCC.

Clang would gave to start having better support for floating point. Right now it's at the "eh, whatever, it works for my limited case" level of support, which is not near good enough for safety-critical applications. They're starting work on that, so maybe in a few years time.

Do you have a reference for this, out of curiosity?

are you saying this in respect to GCC or in regards to commercial compilers, or both?

What does that "diversity" actually gain you? LLVM is very modular so a clang monoculture won't stop competing optimisations etc. being developed, and its license is suitable for most uses.

- The GPL license for GCC is valuable for free software rights.

- just like chrome becoming the only browser, one compiler isn't good either. The implementation starts to define the language instead of the standard

- separate projects can use different methodologies and tradeoffs.

- if there is a bug or exploit that only applies to that complier and not all programs

I don't think we should have 20 major C++ compilers but we shouldn't have one.

> The GPL license for GCC is valuable for free software rights

Apparently not in practice, because LLVM's copyleft license hasn't stopped large amounts of free software from being created (for example, rustc).

The ObjC frontend was only released because Apple got sued for infringing on the GPL.

Fewer people suing each other seems better in my opinion.

How about you comply with the terms of the licence if you don't want to be sued?

But if you use a permissive licence there's no need for anyone to sue anyone at all. Seems a better situation for everyone involved?

Isn't that essentially saying "If nothing were illegal there wouldn't be anyone in prison"?

No it's essentially saying if projects like GCC published permissively we could all get along peacefully and wouldn't need to batter each other using the courts.

The issue there is it removes freedoms from your end users. Now there's a multitude of binary distributions of LLVM, and users can't mix and match pieces of them.

Except one of the things a "permissive" license allows that the "restrictive" GPLv3 doesn't is locking code behind patents.

Companies like Apple prefer BSD specifically because they want the option of taking someone to court if they want to.

LLVM recently re-licensed to the Apache License (v2) which explicitly provides relevant patent grants on contributed works to consumers of the software.

If GCC had been more permissively licensed then Apple would not have released its Objective C compiler, which would have been a worse situation for everyone involved (to include Apple: they are simply wrong that a proprietary compiler is better for them).

GPL tries to make the world better, by increasing the free software commons. BSD tries to be neutral, but one should not be neutral in a war of good vs. evil: (cf. Ireland, Spain, Sweden & Switzerland in the Second World War or Sweden during the Cold War).

And that, along with FSF's earlier refusal to accept patches to let gcc build for the Mac, may be the reason LLVM got the support it did. Two egotistical jerks butt heads, and then one of them found a billion dollars at his fingertips.

Do you have a link to that discussion?

Like gcc has built on mac for longer than Apple (then next step) was using gcc.

1988–1995. https://www.gnu.org/bulletins/bull18.html#SEC13

So the reason for that was that Apple was of the legal opinion that GPLed software was incompatible with their OS. Since they didn't have process boundaries at the time, all code running on the system, even the OS was basically linked together in a big blob. Apple thought (incorrectly) that allowing any GPL software would mean that they had to GPL their OS, and were vehemently anti free software.

I think under those conditions, the FSF's boycott was fair.

Er, no, that wasn't the reason at all. FSF boycotted Apple because of https://en.wikipedia.org/wiki/Look_and_feel#Lawsuits

Do you have any source for that? I found a post[0] on Slashdot from March 2000 that Apple "plans to assign the copyright for its changes to gcc to the [FSF]." Neither the post nor the comments I skimmed seem to make reference to a victorious GPL lawsuit. (Unfortunately the original mailing list post is lost.)

The earliest snapshot[1] of opensource.apple.com on the Internet Archive suggests that the compiler sources were available (under "cc") as of October 12, 2000.

Although that snapshot suggests the first release was version cc-792, I can't find older than cc-798 on the site today. But the NOTES file[2] is interesting, detailing NeXT's/Apple's earlier changes including release codenames. (3/19/97: "This is the first fully functional compiler for the PowerPC.")

I would guess that the earliest Apple shipped gcc was with ProjectBuilder in the Mac OS X Developer Preview which was in 1999. Maybe things start to get blurry with NeXT, WebObjects, etc. but it doesn't _seem_ like Apple was shirking it's responsibilities under the GPL.

0: https://apple.slashdot.org/story/00/03/17/1656240/apple-plan...

1: https://web.archive.org/web/20001012121451/http://www.openso...

2: https://opensource.apple.com/source/cc/cc-798/NOTES.auto.htm...

Ok, so I misremembered, it didn't get to the point of a full lawsuit, only lawyers sending increasingly nasty notes at eachother, but it's still the first GPL enforcement action.

Its was NextStep. They tried for a long time to ship a proprietary GCC, then a proprietary frontend with the rest of gcc, then finally backed down and released the frontend. This was all in the early nineties.

I see. I was just using Nvidia’s CUDA compiler and it seems to be similar—-a combination of a proprietary frontend based on EDG and gcc to produce actual binaries.

It's different, NVCC emits C code, then invokes a version of GCC on that code for the local system.

NextStep was trying to link a new frontend at the same level as C, C++, or Fortran, and just give the middle finger to the terms of the GPL.

Why does good things coming from another license mean GPL isn't working? GPL guarantees a lot of rights that an important minority of developers finds valuable . If you don't care for it, Im not here to convince you, but I think you should be glad it at least exists.

You are right -- the GPL has been enormously important to the free software movement. I (perhaps wrongly) interpreted your post as being anti-permissive more than pro-copyleft. My apologies!

makes sense, I like permissive licenses too.

The existence of LLVM means that GCC's GPL can't really guarantee anything anymore. 20 years ago we got an open-source objective-C compiler because its implementers wanted to reuse GCC's backend. But today a company in the same situation would just use the LLVM backend.

Except with LLVM they wouldn't need to return their work to GCC, like NeXT was forced to do with their frontend.

That's exactly my point. GCC's copyleft was only effective when there wasn't a viable permissive-licensed alternative.

How is a more restrictive licence valuable for anybody's rights?

The GPL restricts vendor rights to protect end user rights.

Hate to pull a Godwin, but that sounds like socialism: let's improve the lives of the common folk by screwing companies. We all know it all ends.

The truth is that free licences gave us the iPhone, the PlayStation, etc.

I've just seen it repeated several times, in many spaces. Apache, for example, moved faster after Nginx started taking market share. And ideas were copied back and forth.

Also, a monoculture isn't great for security/exploits.

Gcc is still the default on GNU/Linux systems which are orders of magnitude more mainstream than FreeBSD.

So what? Clang under OSX compiling both OSX and iOS projects is far more widespread.

On computers-with-keyboards, maybe, probably even.

On a per-kernel basis, absolutely not, even before we consider Androids.

> The Android and ChromeOS Linux distributions have moved to building their Linux kernels with Clang, and Google is currently testing Clang built kernels for their production Linux kernels."

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

You have no idea how many places FreeBSD actually runs in.

Google uses Clang to build the kernel for Android.

Which is interesting but hardly relevant.

To quote:

> > Gcc is still the default on GNU/Linux systems which are orders of magnitude more mainstream than FreeBSD.

> So what? Clang under OSX compiling both OSX and iOS projects is far more widespread.

I'm asserting that there are more Linux kernels compiled under GCC than there are OSX kernels running Clang (so macOS) compiling OSX and iOS projects.

I think that's on pretty solid ground.

Clang is required for all of Android including Linux kernels going forward. Once devices start to age out, this will tip over time.

It doesn't increase the number of macOS kernels, or decrease the number of Linux servers (including virtualized ones, which seems fair), so I doubt it tips the balance.

All I'm saying is that, because of servers, there are more GCC'ed Linux kernels than there are Clang'ed macOS kernels, and this will probably remain true indefinitely.

If AWS starts Clangin' on their Linux kernels, then maybe not. The trend toward Clang is pretty clear at this point; could happen.

Fair point. Google is close to shipping clang built Linux kernels in their data centers (usable VM images for external users already are), but Amazon and Microsoft both have very large clouds as well. I'd guess it's still way less than mobile devices, but I don't have a good sense for how the numbers compare in terms of number of devices in existence for mobile va cloud.

Not on Android, which is an order of magnitude more mainstream than any other Linux distribution.

>Is there some tipping point where gcc has too few significant end users to stay relevant? I'd hate to lose the diversity.

Yes. There will be a tipping point, as with any economic theory of sustainability. No, we wont reach that tipping point in the foreseeable future. It is still extremely widely used, and continue to be actively developed.

LLVM and GCC will likely enjoy duopoly in the Open Source Space for a very long time.

I don't think your question is meaningful in light of why GCC exists at all. It was created to enable people to write free software and, along with binutils, it's hard to imagine any software that's been so profoundly influential in the free and open source software that we have today.

I think GCC will remain relevant for as long as there are people who care about free software.

I removed GCC from AOSP a month ago.

https://android-review.googlesource.com/q/topic:%22rm_gcc%22...

We never had it in Fuchsia being LLVM/Clang only from day one. Technically zircon had a GCC builder for a bit though to compare kernel builds.

So FreeBSD was supporting GCC 4.2.1 but not upgrading to newer GCCs over the years. GCC is currently at 9.2.

Apparently the reason for this is GCC's move to GPL v3. So FreeBSD was forced to remain using GCC 4.2.1, GPL v2.

As far as Clang goes, is FreeBSD tracking/upgrading to newer Clang versions? I assume the answer is yes but I don't know.

Yes, they are updating it regularly: https://svnweb.freebsd.org/base/head/UPDATING?revision=35849...

Yes, GCC 4.2.1 for tier 2 and 3 architectures only (like MIPS or PPC) for quite some time.

Clang/LLVM was imported into FreeBSD base in FreeBSD 9, released in 2012[1]. I don't believe it was the system compiler for any arch at that time, but could be wrong. In FreeBSD 10 (2014) it became the default compiler for amd64/i386[2].

[1]: https://www.freebsd.org/releases/9.0R/announce.html

[2]: https://www.freebsd.org/releases/10.0R/relnotes.html

"Forced" is a bit of an overstatement. Other BSDs ship with newer versions of GCC, FreeBSD just disagreed with the GPLv3 tivoization clause.

Can anybody explain the hate/aversion towards GCC? As I see it clang used to generae more meaningful error messages thats why many people turned toward clang. But it seems those days are gone.

Gcc still produces better=faster machine code. So why the hate? Are there political reasons involved?

> Are there political reasons involved?

GCC is more spaghetti than Clang, less modular. But yeah, it's mostly political/business/legal related. A lot of people hate copyleft with a passion like Apple and Google, who hire lots of people to work on LLVM.

The idea seems to be that LLVM will eventually catch up to GCC on quality of generated code.

Google didn't move to clang/llvm because they hate copyleft. They moved because people who work on compilers prefer to work on clang/llvm, and if you have a compiler group you need to keep them happy.

It's probably also true that the FSF is more of a pain to work with than absolutely necessary — they want copyright assignment, have some abhorrent code style, and still insist on tracking useless diff summaries in ChangeLog files long after the invention of RCS systems.

Hate is probably too strong a word but there is a contingent within the BSD community who perceive the GPL as "viral" and actively work to make as much of the project BSD-licensed (or similar) as possible.

Could someone explain the particular pain points of GPLv3 as it relates to use of gcc?

They've been trying to achieve this for decades, mainly for perceived ideological differences.

That's totally fine if you're talking about a workstation, laptop, or server. But it's a big security risk on an embedded system like a smart TV, mobile phone, or game console - 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.

That's a rationalization though, not the reason. FreeBSD's GPL "exorcism" efforts had been going on long before FSF started floating ideas about GPL 3.0.

FreeBSD has removed GCC from base system but GCC is still available as a port

What about binutils? Is it removed too?

Mostly, we still have a couple of binutils hanging around:

- ld.bfd on 32-bit powerpc (should go when lld 10.0 is in FreeBSD)

- GNU as on i386 and amd64 (expected by some ports, and needed to assemble one file in the base system on amd64)

- objdump (expected by some ports, but not used in the base system)

These should be removed in FreeBSD 13.0. More details are on our Wiki, https://wiki.freebsd.org/GPLinBase

Well from my understanding FreeBSD was using an old version of GCC mainly because licensing reasons. What's so annoying about the licensing around GCC is I see a lot cases where the code generation is still better than clang. Although clang matches GCC in most cases.

I guess we shouldn't be surprised. BSD has no philosophical reason to keep GCC over Clang, and if Clang is delivering better performance for them, obviously they're gonna use it.

Where does it say that it delivers better performance than GCC? AFAIK the main reason they switched is the license.

Regardless of what the situation was back in 2007, one tends to imply the other over time: the version of GCC is ancient now (because of licensing issues) and of course clang will do better: it has an extra decade of compiler development.

In the future, gcc will be remembered (fondly!) as historically significant between the time periods of simple unix-based K&R C compilers of many years ago -- and Clang, of the past few recent years...

Reply on news.ycombinator.com