Rebuild of the Debian archive with clang
Recently, I have been working on a side project for Debian. The goal was to rebuild of the Debian archive (the distribution) with clang, a new C/C++ compiler.
clang is now ready to build software for production (either for C, C++ or Objective-C). This compiler is providing many more warnings and interesting errors than the gcc suite while not carrying the same legacy as gcc.
This rebuild has several goals. The first one is to prove (or not) that clang is a viable alternative. Second, building a software with different compilers improves the overall quality of code by providing different checks and alerts.
The result are detailed and explained here:
http://clang.debian.net/
Conclusions
When I had the idea to rebuild Debian with a new compiler, I was expecting many issues and bugs caused by clang but I have been surprised to notice that most of the issues are either difference in C standard supported, difference of interpretation or corner cases.
My personal opinion is that clang is now stable and good enough to rebuild most of the packages in the Debian archive, even if many of them will need minor tweaks to compile properly.
In the next few years, coupled with better static analysis tools, clang might replace gcc/g++ as the C/C++ compiler used by default in Linux and BSD distributions.
The clang developers are progressing very fast: 14.5% of the packages were failing with version 2.9 against 8.8% with version 3.0.
Several major steps in the clang adoptions have been made like chromium/chrome being built by default with clang, Xcode providing clang by default, FreeBSD working on the gcc -> clang switch, etc.
However, on the Debian point of view, one of the important step would be to make sure that clang manages all the Debian architecture/kernel (11 official, 6 unofficial)
11 commentaires
Now that Apple is gaining influence in the development of LLVM, don’t you see a risk that it suffers the same fate as cups? See the recent developments of cups 1.6 wrt Linux.
I have been following the llvm-commits mailing list for a while and Apple people are not doing half of the commits.
There are Google, academic, etc contributing on a daily bases…
For example, I didn’t have issues to see my patches applied quickly (even the one for HURD).
Clang is real threat to all free world cause of apple have its hands on it.
I hope clang not become a default compiler in linux distros. Do you know why BSD want to propose clang? They are hate GNU GPL license, thats it. There is no other real reason why do they refused to use gcc in their system. They can’t understand, that GPL is good for both developers and users, while BSD good only for companies.
At least LLVM is developed by people from different companies, while gcc is at least 90%, probably more, developed by a single company: Google.
Can you give a list of all packages with their errors.
I am trying to find (OCaml) packages with error and it will be useful to have all the problematic packages on the same pages, whatever their error is.
Thx
Sylvain:
http://clang.debian.net/scanlog-3.0-2012-01-12
with clang 2.9
http://clang.debian.net/scanlog-2.9-2011-09-11
Would be nice with per-package-maintainer web pages.
Also, per-package web pages and (poking Paul Wise to add) links from packages.qa.debian.org summary pages would be awesome.
@Jonas: Right, I will do it!
dd-list will be cool addition :)
All this whining about LLVM/Clang. What a joke. The quality of architecture alone, nevermind the contributions by hundreds of architect level quality developers of compiler expertise is producing a far superior product to GCC.
You get all of this for free.
You get CUPS for free. Nothing is stopping any Distribution of Linux to pair up the quality of CUPS with that of Apple.
Can you provide search by package name or source package name on clang.debian.net? It will make easier to check if packages I care is affected. Also package size comparission (before and after compressing into .deb, and default ones from Debian) of this packages which successed would be usefull.
Another question: what architecture you was using? amd64? How about i386? It should be equally easy (in terms of access to building virtual machines), and when considering metrics like package (binary) sizes changes beetween clang and gcc, it can give better insight into any changes.
Les commentaires sont clos : ce blog est une archive statique.