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:
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)
Yesterday, I uploaded hdf5 1.8.8 in unstable. This new version, which has been available in experimental for a while, is a major step in the HDF5 packaging.
For those who are using this package, besides the switch from version 1.8.6 to 1.8.8, the changes are the following:
- Since upstream is now trying to keep a consistent ABI/API, packages have been renamed from libhdf5-xxx-X.Y.Z (X, Y and Z being the version number) to libhdf5-xxx-7 (7 being the version of the soname)
- The package libhdf5-serial-* have been renamed to libhdf5-7 or libhdf5-dev
- Symbol files have been added for all the libraries.
- arm archs have also libhdf5-openmpi-dev
- Support of HURD, armhf & s390x
- Help is now up to date and the debian/html.tgz.uu removed (thanks to the source format v3.0, two source tarballs are now used)
- A new package hdf5-helpers which contains h5cc, h5c++ and h5fc has been introduced
- Fix many lintian warnings
- Java HDF has been updated to version 2.8
More information about the transition:
The principle of a BSP is to gather Debian contributors to tackle a maximum of bugs in Debian.
This event is also the opportunity for new potential contributors to meet Debian Developers or Maintainers. Numerous regular contributors will attend to this BSP and will help newcomers to fix their first bugs.
For organization reasons, an inscription on the Debian wiki is mandatory.
Non-Parisian can find a list of hostel close to the IRILL's offices.
As said in one of my previous blog post, we, Debian, were going to remove sun-java6 packages from the archive once critical security issues would come. It was supposed to happen sooner and later and here we are. The version 29 (see the #645881 Debian bug) of the Oracle proprietary JVM has been released. It fixes some critical issues but, because of the DLJ removal, Debian is no longer able to distribute it.
Unfortunately, we have no other choice than asking for a removal from the archive and promote the use of the openjdk 6 & 7.
The conclusion is:
apt-get --purge remove sun-java6-jre && apt-get install openjdk-7-jre