Building LLVM 2.5 on CENTOS 5.3

Hi Folks,

I'm having some difficulties getting LLVM to build and work correctly on CENTOS 5.3. This is basically tracked down easily enough to CENTOS using GCC 4.1.x by default, which is known-buggy and known not to work with LLVM -- I was getting the well-known problem with aborts due to a non-empty symbol table. I have installed the gcc43 package via yum (I'm trying to stick to known packages because I need to roll this out at some point), which installs a gcc43 executable. Is there any configure magic available that will make it possible to get the LLVM build system to pick up gcc43 rather than the default gcc? Symlinking it didn't work, because I suspect it was still picking up the old libraries and headers. This is preferable to requiring users to significantly hack their environment.

Sarah Thompson

I haven't tried it, but comments in 'configure' suggest the CC and CXX environment variables should work.

Am trying that currently... looks OK so far. I'll post results when I've run my regression tests. Thanks!


OK, that got much further, but I'm now seeing another problem which may (or may not) be related. Building my own code (my model checker), it builds libraries fine, then within tools (I'm using a fairly standard LLVM build environment here), I am seeing the error

  *** llvm-config doesn't exist - rebuilding it

followed by a

  make: Entering an unknown directory

which is complaining about .../tools//bin/llvm-config

This didn't happen when I was building with gcc 4.1.x, though of course, my code didn't actually work when compiled with that compiler.


That's odd. It's the "/bin/" in there that make is complaining about.
I'm not sure why a different compiler would cause it to change
behavior. Does adding "VERBOSE=1" to the "make" command shed any light
on what's going wrong here?


Hmm... looks like my LLVM build script only built debug versions of the tools, not release versions. I'm investigating, I didn't change anything that should have caused that.


Hmm... looks like my LLVM build script only built debug versions of
the tools, not release versions. I'm investigating, I didn't change
anything that should have caused that.

That's the default. You need to build with ENABLE_OPTIMIZED=1 (or configure with --enable-optimized, I think). Use VERBOSE=1 to see what's going on.

We build debug by default. You will have to add ENABLE_OPTIMIZED=1 on
the "make" command line or --enable-optimized during configuration.


OK, definitely something wrong here. I'm seeing errors along the lines of:

/usr/bin/ld: /home/user/rse/llvm/build/Release/bin/fpcmp: hidden symbol `void std::__ostream_fill<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, long)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

as each tool is linked in release mode. This doesn't happen in debug mode (i.e. they seem to link fine).


(My script does both of those -- the debug build worked (I think), but the release build fails)


Just to give closure here, I eventually gave up, built an Ubuntu 9 VMWare image which uses gcc 4.3.2 by default, installed Eclipse Ganymede and various other tools, then built LLVM 2.5 and my own code. It all ran fine. There is clearly something broken in the CentOS gcc43 package. Definitely one to avoid.


Hello Sarah,
just to give you a hint of something that might happen:
I am in the same situation on suse linux with gcc 4.1 as the system's compiler,
so I built 4.3 as an alternative from sources. Everything went well for
quite a long time, but eventually my program would crash at runtime
on something as simple as passing a std::string by value or reference.
It turned out that I had to use LD_LIBRARY_PATH to make it load of the 4.3 installation. The nasty thing is that this seems to
cause problems very rarely.
Just in case you notice that your application runs fine in the virtual machine
but not anymore once rolled out...