[LLVMdev] Build problem with nonstandard lib directory

Andy Jost Andrew.Jost at synopsys.com
Sun Jun 30 18:12:12 PDT 2013


I'm having trouble building LLVM 3.3 on RHEL 2.6.9-89.ELlargesmp x86_64.  This is most likely a problem with my not knowing the advanced usage of the configure script, but I'm stuck just the same.  I hope this list is an appropriate place for this question.

The system I'm working on is a bit unusual.  It is a shared server not administered by me (I can't change the configuration), and the "normal" system directories like /usr/include, /usr/lib and so on contain mostly very old and outdated things.  For instance, /usr/bin/g++ is gcc version 3.4.6.  I access newer versions though a non-standard directory, e.g.,  /depot/gcc-4.5.2/bin/g++ is gcc version 4.5.2 (the version I want to use).

I've checked out the LLVM 3.3 code, and I try to configure and build it like this:

../src/llvm-3.3/configure --enable-doxygen --enable-jit --prefix=`pwd`/bin
gmake -j12

After several step succeed, I eventually get the following error:

<clip>/build/Debug+Asserts/bin/llvm-tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.5' not found (required by <clip>/build/Debug+Asserts/bin/llvm-tblgen)

I know this error.  It occurs when the default /usr/lib64 path is used for dynamic loading instead of the non-standard /depot/gcc-4.5.2/lib64.  Normally, I need to set LD_LIBRARY_PATH on this system.  I confirmed that with LD_LIBRARY_PATH set, I can invoke llvm-tblgen, and the without that variable set, I get exactly the error shown.  Also, LD_LIBRARY_PATH is correctly set when configure is called, and when gmake is called.

So how can I adjust the build process?  I suspect there is an option I can pass to configure, but I haven't been able to figure out what it would be.  For example, I tried adding LD_LIBRARY_PATH=$LD_LIBRARY_PATH to the configure command line to no avail.

Any help would be greatly appreciated!

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130701/0ef45de0/attachment.html>


More information about the llvm-dev mailing list