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.
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).
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.
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.
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.
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.
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.
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.
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].
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.
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.
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
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.
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
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.
39 comments
[ 0.21 ms ] story [ 123 ms ] threadhttp://compcert.inria.fr/compcert-C.html
EDIT: See also https://github.com/AbsInt/CompCert
see also http://blog.regehr.org/archives/1036#comment-12057
I wonder what it would take to make Rust 1.0 + LLVM into an LTS?
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.
So you want something for nothing. Why exactly would Ubuntu (or anybody else) want you as an user?
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.
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.
Just try to update a compiler version on a large code base, specially in corporations where developer tools are managed by IT support.
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
pccm is naturlly where they're headed. It's just not ready yet.
Users can use a different compiler by specifying it on the command line via e.g.
Some people set in their Makefile to force the usage of gcc. Never do this. Do this instead: That way users can still override the value of ${CC} on the command line if they want to.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.
Wont any LTS compiler be "too old" quickly?
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
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.
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.
Why again?
Why again?