Compilers in OpenBSD (2013) | Hacker News Reader

Compilers in OpenBSD (2013)

marc.info

77 pointsfcambus34 comments

Curious if the folks at OpenBSD have ever thought about giving CompCert-C a shake. I realize it's no gcc or llvm, but OpenBSD is no run of the mill *nix, either.

http://compcert.inria.fr/compcert-C.html

EDIT: See also https://github.com/AbsInt/CompCert

The license of CompCert is an instant no to be part of base in openBSD. I believe the reason openBSD hasn't changed to llvm is because it doesn't support all of their current architectures(feel free to correct me on this).

Here's a link explaining why they haven't switched yet: http://marc.info/?l=openbsd-misc&m=137530560232232

The idea that older versions of GCC didn't have as many bugs doesn't hold up to any scrutiny: http://blog.regehr.org/archives/1036

Not all compiler bugs are equal. Miod has a pretty good sense of which compilers exhibited the worst bugs in practice and the effort required to fix/workaround them.

Well done.

It is really worrying because it seems to be the trend with everything, from web browsers, compilers, all the way down to kernels.

This was my favorite quote: "The free software world needs an LTS compiler."

Of course, everybody wants to have an LTS release of every piece of software they depend on, that "just works" for all their use cases [1], and that somebody else maintains for many years, like magic.

The problem is, nobody wants to pay for its maintenance, hence it does not exist [2].

In the FOSS world, nobody is entitled to a pony.

Also it's rather ironic that it's an OpenBSD developer wanting this, considering http://www.tedunangst.com/flak/post/long-term-support-consid... - how does that reasoning not apply to compilers?

[1] including of course the all-important Motorola 88k back-end!

[2] with very few exceptions: RHEL, SLES

Miod and I have different opinions. Anyway, what I think Miod really wants is a compiler free from regressions. Unfortunately, new compiler versions tend to introduce at least as many regressions as bug fixes.

That's not true for all open source projects. Look at PostgreSQL for instance, they back-patch all bugfixes (where possible) to all of the previous supported major versions.

The enterprise world already had them since decades.

Just try to update a compiler version on a large code base, specially in corporations where developer tools are managed by IT support.

Agree.

I wonder what it would take to make Rust 1.0 + LLVM into an LTS?

Rust 1.0 represents a foundation for the language, rather than the ultimate expression of it. A LTS release could be a good idea, but I don't see it happening for at least a year or so.

Sorry to be that guy, but what's an LTS compiler? (Google was not forthcoming.)

LTS as in Long-Term Support:

http://en.wikipedia.org/wiki/Long-term_support

The basic idea is that once released, the LTS version of the compiler would continue to receive fixes and updates for several years (at least two according to Wikipedia), no matter how many new versions are released during that time.

LTS means long-term support, which means freezing features and maintaining that version for 2-5 (or more) years.

Also LTS means "95% of the developers left for the newer version because on open source projects no one can be forced to work on legacy applications like in business world".

Good luck with that. I tried to go on with the Ubuntu's LTS once, and the logic definitely doesn't work. Bugs, even major ones, just pile up faster than the remaining couple developers can fix, and it's was too painful of an experience to repeat. Ubuntu LTS has shelf life of 6-12 months unless if you start paying. Which is unfortunate.

95% of the developers left for the newer version because on open source projects no one can be forced to work on legacy applications

Yep. I see this a lot in the scientific world. Clusters and other high-performance hardware run old versions of Scientific Linux or CentOS (because they are well-supported and the bugs are known). However, a lot of open source project (e.g. in machine learning) expect you to run the latest Ubuntu or OS X version. Result: you usually end up hand-compiling large amounts of software, manually adding '-I' and '-L' flags to oddball build systems that don't pick up CFLAGS or LDFLAGS correctly.

Nobody cares about backwards compatibility, everyone wants the new toys.

> unless if you start paying. Which is unfortunate.

So you want something for nothing. Why exactly would Ubuntu (or anybody else) want you as an user?

I want "something", that something being backwards compatibility and long-term support, for $100-150. Can I get it from Ubuntu or any other Linux/Unix? I sure as hell get it from Microsoft.

definitely

Great place to shamelessly mention my MIT licensed work in progress C compiler (written in Go), https://github.com/andrewchambers/cc/ . Nowhere near the level it needs to be, but would be fun if I could start a community to push it forward.

12 years ago miod and marc talking of openBSD http://www.libroscope.org/OpenBSD-ne-desarme-pas (fr)

or miod taking is sherlock holmes hat to solve a GCC bug http://www.onlamp.com/pub/a/bsd/2003/10/02/openbsd_gcc.html

Yes I am a fanboy of miod, and I am not even ashamed.

> The last de-facto LTS compiler we have had was gcc 2.7.2.1, and it is too old to compile modern C and C++ code.

Wont any LTS compiler be "too old" quickly?

Depends on your code. C isn't moving at the pace C++ is so given that most (all?) of the OpenBSD base is C and sh, LTS will work with base, no problem. It's important too that developers are rather happy with what C99 brings to the table so it's a solid reference point for any LTS compiler that would/could happen. It's ports, I think, where the problem is. A lot of that code is C++ so you need compiler and std lib implementation to be able to handle it. But there are two problem.

First one: the quality of ports varies from project to project. There's code out there that depends on certain gcc-specific extension, compiler quirks, bugs, you name it. C++ is insanely complex and features just keep piling on. I bet the moment C++17 is available some projects start using certain features because they can. In this case C++ is a moving target and it's hard to imagine LTE C++ compiler for open source projects.

Second one: AFAIK only gcc's standard library has support for all of the wacky constructs C++ requires. You're probably out of luck if you try to compile C++ code with thread local storage intermingled with exceptions and you want to depends on non-GPL musl or bionic (which would be important for projects like OpenBSD). And there's code depending on that in ports, you can bet on it.

Until these problems are solved[1], OpenBSD won't migrate. LLVM could become the LTS compiler for projects that would benefit from using it, but it doesn't look like a complete operating system is a project that would fit.

[1] plus some others, like backends available for more than x86/64, arm, mips, PPC, Sparc and z (or whatever the list is today); OpenBSD supports quite a few esoteric platforms

If obsd moves to clang I'll eat my hat.

pccm is naturlly where they're headed. It's just not ready yet.

On a somewhat related note, I found it amusing that in OS X gcc has been aliased to clang.

It's a practical concern, really. Too many people wrote Makefiles which called gcc instead of cc.

Traditionally on most Unix systems cc and gcc where two different compilers. Many times people would write code in ways that compiled with gcc, but not cc, so specifying exactly which compiler you want makes sense.

It might be bit ugly, but couldn't you use a variable inplace of the compiler name, so that it would be trivial for someone to attempt using another compiler

That is exactly what make supports out of the box. If ${CC} is missing from the Makefile, ${CC} is globally set to the system C compiler i.e. cc

Users can use a different compiler by specifying it on the command line via e.g.

  make CC=clang

Some people set

  CC=gcc

in their Makefile to force the usage of gcc. Never do this. Do this instead:

  CC?=gcc

That way users can still override the value of ${CC} on the command line if they want to.

> CC?=gcc

This is only relevant if you want portability to other versions of Make. I simply don't care about anybody who's not using GNU Make these days. Try it yourself: command line options override variables in makefiles unless "override" is specified for that assignment.

Old discussion: https://news.ycombinator.com/item?id=6141319

Why again?

Reply on news.ycombinator.com