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.
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?
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).
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.
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
libstdc++.so 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...