[cfe-dev] Cleaning up the clang::driver::toolchains::Linux mess?

[Anders Kaseorg]

clang 2.9 hardcodes a huge list of GCC versions and paths and distro 
release files in /etc just to find where GCC keeps its libraries and 
include files on Linux.  This was introduced in 
http://llvm.org/viewvc/llvm-project?view=rev&revision=118382 , and it’s 
been patched up several dozen times since then with uglier and uglier 
distro-specific hacks.

Lately this has been causing trouble for Debian and Ubuntu development 
releases, which have been transitioning to multiarch paths for GCC, such 
as /usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6.1; see 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629861 .  But more 
fundamentally, it seems fragile, unmaintainable, and most other kinds of 
wrong.  It’s guaranteed to break again every time a new GCC version or a 
new distro release comes out, and even if clang gets fixed promptly, not 
every distro has the resources and energy to package a new version of 
clang every time that happens.

Is there a sane way to find these paths?  It seems GCC has an option to 
just output them:

$ gcc -print-file-name=crtbegin.o 
/usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6.1/crtbegin.o

This would preferably happen at clang’s configure time so the packager can 
override the autodetection if it fails for some reason.  It might even be 
possible to parse all the necessary distro-specific flags (-z relro, 
--hash-style=gnu, etc.) out of `gcc -dumpspecs`.

Anders