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

[James Molloy]

Hi,

If you're thinking of doing this sort of refactoring (and I agree it is definitely worthwhile), could you please not just limit it to toolchains::Linux?

I'm thinking more of toolchains::Unknown, which is used when cross-compiling to bare-metal and currently calls GCC to find the assembler and linker (but LLVM/Clang is meant to be a GCC replacement - it shouldn't rely on it!).

I've been doing some work on improving the cross-compilation story in the Clang driver (see  http://comments.gmane.org/gmane.comp.compilers.clang.scm/36110, currently stuck at review on cfe-commits), but haven't got around to doing something about toolchain locations yet.

An option to bake in locations at configure time a-la GCC would be excellent for picking up the correct cross-compilation linker, assembler and libraries.

Cheers,

James

> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of Anders Kaseorg
> Sent: 14 June 2011 00:03
> To: Rafael Espindola; cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] Cleaning up the clang::driver::toolchains::Linux
> mess?
> 
> 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
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev