From the latest -current FAQ:
2017/04/19 - clang enabled for amd64 and i386
The clang compiler is now built alongside gcc on the amd64 and i386 architectures. It is recommended that you upgrade using a snapshot. If you build your own releases, note that make release now needs more than 2G space on /usr/obj. Increasing the size to 3G is recommended.
Stories with similar links:
- Various OpenBSD architectures switched to PIE by default via lynge 10 years ago | 9 points | 1 comment
[for the record] commit from TdR two days ago: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/share/mk/bsd.own.mk?rev=1.184&content-type=text/x-cvsweb-markup&sortby=date
“ship clang with i386 and amd64. It does not become the main compiler YET. ok kettenis”
Does this mean clang is used to compile OpenBSD by default on those architectures, or just that it is available to do so (with the default still being gcc)?
It is the default on arm64, and available as an option on amd64 and i386. The ports guys are shaking out the bugs in the ports tree using clang, and other developers are working to get the full base tree and kernel working with clang, so that it can become the default on those platforms later.
I’m curious what is the motivation for switching to clang?
I’m not involved in that area (maybe @bluerise can chime in) but our GCC is pretty old because it’s the last GPLv2 release and we won’t import any GPLv3 code from the newer releases. Our new arm ports needed clang, and since the license was acceptable, it was imported into base. Since llvm is modern, actively maintained, and has some extra bells and whistles for finding errors, we’re going to switch the other major architectures to it slowly over time, once all of the bugs have been worked out.
Thanks, I figured it had to do with licensing. As someone ambivalent about copyleft vs. permissive licensing I’m sorta sad that these issues cause projects like OpenBSD to move away from projects sponsored/controlled by software freedom organizations, to projects sponsored/controlled by tech giants. I’m sure OpenBSD has their reasons for refusing GPLv3 and GNU has their reasons for insisting on it, it’s just frustrating to watch from the outside.
Copyleft free software code likewise depends on companies to a large extent. See codesourcery’s involvement in gcc, redhat and intel employees writing linux userland and kernel code, etc.
Adding to what stsp said, look at e.g. http://www.infoworld.com/article/2610207/open-source-software/who-writes-linux--corporations--more-than-ever.html
It’s only a false stereotype that Linux is developed by basement dwellers. Many of Linux Foundation members are actually hostile to FOSS. There has even been recently an article from Linux Foundation where they criticise GPL ( http://fossforce.com/2017/04/lin-desktop-linux-gpl-openness/ ), but when it caused controversies, they removed it.
naddy@ just explained the motivation quite well here: http://marc.info/?l=openbsd-misc&m=149271783012704&w=2
Is the eventual goal to remove GCC from the base system entirely and into ports? Thanks.
It will still have to be used for some older architectures, so I don’t think it’s going anywhere.
My biggest complaint so far is having two clangs - maybe someone can provide a workaround?
Two LLVM/Clang builds will exist for most now because the ports system still has many dependencies on devel/llvm and aren’t using or recognizing base-clang - hopefully that will change in the near future and is a temporary transition side-effect.
clang in ports was largely just used as a dependency for a few other ports that needed it to compile. Now that it’s in base, all packages are being built with it so the ports team can find and fix the problems with individual ones (like those hard-coding
CFLAGSto things that don’t work with clang). This process takes time and manual work for our small ports team.I would imagine once that is done, the clang port would go away unless the port offers flavors for other languages or features that depend on things we don’t have in base (I haven’t checked).