problems building llvm-gcc-4.2 on fedora 21

Hello,

I am very new to llvm, but I need to have a fully working llvm /
llvm-gcc system built and running on my fedora 21 virtual machine so I
can perform some concolic testing with stp.

I have installed all upgrades to fedora 21 using yum upgrade.

I was able to compile and install llvm fine from the svn repository.
I checked out llvm-gcc-4.2 from the repository (revision 234124).
I ran configure as:
$ ../llvm-gcc/configure --program-prefix=llvm-
--enable-llvm=/home/draikes/src/llvm-obj --enable-languages=c,c++
--disable-multilib
when I run:
$ make

I get the following errors:

/home/draikes/src/llvm/include/llvm/ADT/StringRef.h:346:19: error:
â EURO ~enable_ifâ EURO (tm) in namespace â EURO ~stdâ EURO (tm) does not name a template type
     typename std::enable_if<std::numeric_limits<T>::is_signed, bool>::type
                   ^
/home/draikes/src/llvm/include/llvm/ADT/StringRef.h:346:28: error:
expected unqualified-id before â EURO ~<â EURO (tm) token
     typename std::enable_if<std::numeric_limits<T>::is_signed, bool>::type
                            ^
/home/draikes/src/llvm/include/llvm/ADT/StringRef.h:357:19: error:
â EURO ~enable_ifâ EURO (tm) in namespace â EURO ~stdâ EURO (tm) does not name a template type
     typename std::enable_if<!std::numeric_limits<T>::is_signed, bool>::type
                   ^
/home/draikes/src/llvm/include/llvm/ADT/StringRef.h:357:28: error:
expected unqualified-id before â EURO ~<â EURO (tm) token
     typename std::enable_if<!std::numeric_limits<T>::is_signed, bool>::type
                            ^

Is there any good way to work around this problem? I am not a strong
c++ programmer, so I need as much help as possible.

Thank you in advance,
Donald

llvm-gcc is dead. Please use clang.

Joerg

If you really need GCC as a front-end for some reason, consider using DragonEgg:

http://dragonegg.llvm.org

That page is somewhat out of date, but there is good information in the LLVMdev archives.

Brian

Keep in mind that dragonegg no longer has a maintainer and is rapidly
bit-rotting. In particular, it only supports FSF gcc up to 4.8 and is
unlikely to move beyond that in the absence of a new active
maintainer.
          Jack