Just a quick heads-up:
The ./configure in the llvm 2.2 package will work on my amd64 machine
with this command line:
./configure --prefix=$HOME --enable-optimized \
--build=i686-pc-linux-gnu CC=gcc-4.2 CXX=g++-4.2
Note that the CC and CXX flags are set on the command line, not as
environment variables - trying to submit them via the environment got me
all kinds of breakage.
Also not that this needs to set just --build, not --host (which defaults
to the setting of --build) nor --target (which defaults to whatever
value --host ends up as).
Now the ./configure in llvm-gcc4.2 as of version 2.2 will choke badly on
such a command line.
First, it misinterprets the CC= and CXX= strings as target architecture
names, and continues to complain that it cannot configure for multiple
architectures at once.
Second, it does not default --host or --target to --build.
Third, even with --target and --host explicitly set to
i686-pc-linux-gnu, the assembler will be fed with 64-bit code. The
failing command is
-isystem /home/jo/i686-pc-linux-gnu/sys-include -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I. -I.
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer
-c /home/jo/llvm-gcc-src/gcc/crtstuff.c -DCRT_BEGIN -DCRTSTUFFT_O
(slightly edited to leave out multiple blanks and line continuation
The error messages are just what I had seen earlier:
/tmp/ccVjR8Qt.s: Assembler messages:
/tmp/ccVjR8Qt.s:33: Error: suffix or operands invalid for `push'
/tmp/ccVjR8Qt.s:43: Error: suffix or operands invalid for `call'
/tmp/ccVjR8Qt.s:61: Error: suffix or operands invalid for `push'
/tmp/ccVjR8Qt.s:71: Error: suffix or operands invalid for `call'
It seems that the ./configure for llvm-gcc is doing some, er, seriously
nonstandard things with autoconf...
This is close to a showstopper for integrating an llvm-gcc bootstrap
into the nightly tester. The llvm-gcc ./configure needs to be called
very differently from the llvm ./configure, and keeping two set of
options is Not Worth The Trouble, at least IMHO.
Next thing I'll check whether the same problems occur with SVN trunk.
P.S.: Don't worry, I'll use LLVM for my projects even if I don't manage
to bootstrap it or run the nightly tester