with 'old' gcc: Request for comments


Just a quick refresh, on [1], I am rebuilding the sources
of LLVM to create snapshot packages for the stable branches
and development branches (currently, 3.4, in the hope of point releases
and 3.5). This currently targets 2 releases of Debian and 4 of Ubuntu
[2] and the llvm
toolchain is built using the compiler shipped with the distribution.

Following the recent discussions on the usage of C+11, we have now/soon
a requirement on having a recent and C++11 compiler. [3]
That requires a recent version of gcc (for example, 4.6 is not working).
Unfortunately, more recent versions are not available in Debian wheezy
(current stable) or Ubuntu precise (an Ubuntu LTS).

The usage of a backported version of gcc is not really feasible because
it would trigger a dependency on libstdc++ 4.8 [4] and the installation
by the user
of the backported gcc.

For now, the obvious solution would be to drop the support of these
releases but there are still many users of these distributions.

Any suggestions? Static linkage of libstdc++? Usage of libc++? Usage of
clang 3.4 to bootstrap them?


[3] For example, currently, lldb fails to build with
sorry, unimplemented: non-static data member initializers
error: 'constexpr' needed for in-class initialization of static data
member 'm_mutex' of non-integral type
or fails to link with:
18077 – fails to link under GNU/Linux powerpc & mips

Hi Sylvestre,

The easiest is probably to have a dependency to (and use) clang-3.4 to bootstrap.


After some thinking on this idea, it would not work because I need / want to use Debian/Ubuntu package to do the build and clang 3.4 is not built on these architecture :frowning:
So, if I bootstrap clang 3.4, I will have a dependency on libstdc++ 4.8… :confused:

Wouldn’t it be possible to fetch some binaries for the 3.4 compiler ? I agree this is not as-elegant as you may want it, but this is all about seeding the very first build. This inelegant step can be dropped as soon as you have a shiny new clang-3.5 which you would be using to bootstrap later snapshots / releases.


Seems dangerous and this isn't Windows - Distro and users should be able to reproduce the build from sources

I have no Windows experience… The binaries may not be coming from an obscure location, but either from (where the way they have been built is documented and can hopefully be reproduced), or directly from debian/ubuntu repositories, where they would have been built using the same procedure than at A third approach, would be to build (locally) a clang-3.4 first thing each time you want to build later releases. Seems a bit of a waste of processing power though ;). The point here is just to be able to seed the build for the first iteration. Then, after a few monthes, the build scripts can be changed to not rely on those binaries any longer.