[LLVMdev] switching to llvm-g++ as the host compiler
Stuart Hastings
stuart at apple.com
Mon Jul 6 15:47:00 PDT 2009
IANACE (I Am Not A Configury Expert :-), but I've been asked to
reconfigure LLVM and LLVM-GCC to build with LLVM-GCC (perhaps more
accurately, LLVM-G++).
The patches to do this are short. In the LLVM tree, this suffices; it
looks for LLVM-GCC first, and if that fails, falls back to GCC:
Index: llvm.test/autoconf/configure.ac
===================================================================
--- llvm.test/autoconf/configure.ac (revision 74729)
+++ llvm.test/autoconf/configure.ac (working copy)
@@ -601,8 +601,8 @@
dnl Check for compilation tools
AC_PROG_CPP
-AC_PROG_CC(gcc)
-AC_PROG_CXX(g++)
+AC_PROG_CC([llvm-gcc gcc])
+AC_PROG_CXX([llvm-g++ g++])
AC_PROG_NM
AC_SUBST(NM)
Likewise, in our LLVM-GCC tree, this seems to work for Darwin/x86:
Index: llvm-gcc.test/configure.in
===================================================================
--- llvm-gcc.test/configure.in (revision 74729)
+++ llvm-gcc.test/configure.in (working copy)
@@ -993,10 +993,10 @@
# APPLE LOCAL begin dynamic-no-pic
i[[3456789]]86-*-darwin*)
host_makefile_frag="config/mh-x86-darwin"
- # gcc can default to x86_64 code generation, avoid that
+ # llvm-gcc can default to x86_64 code generation, avoid that
if test "${build}" = "${host}"; then
- CC="${CC-gcc} -m32"
- CXX="${CXX-g++} -m32"
+ CC="${CC-llvm-gcc} -m32"
+ CXX="${CXX-llvm-g++} -m32"
fi
;;
# APPLE LOCAL end dynamic-no-pic
I've done some light testing of these, and I'm convinced they will
work, at least for those of us on Darwin. The latter patch is Darwin/
x86-specific, and hopefully non-contentious. I would hope the former
patch wouldn't break anybody, but I thought I'd ask before applying it.
Of course, I'm omitting the diffs resulting from the re-auto-
confiscation of both trees. I was obliged to tweak all the version
checks in the LLVM file AutoRegen.sh in order to get it to run :-),
but no errors turned up after my hacking. (Should AutoRegen.sh be
updated too?)
Comments invited; if there's a better approach, please share.
stuart
More information about the llvm-dev
mailing list