[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