[cfe-dev] How to get clang++ to add appropriate -rpath option when using non-standard location for libstdc++.so
Glenn Coombs
glenn.coombs at gmail.com
Wed Feb 11 08:53:20 PST 2015
Hi,
I am trying to build clang++ 3.5 on a CentOS 5.10 machine. The system
installed gcc is 4.1.2. I do not have root access on this machine and have
therefore built and installed gcc 4.8.2 into a non-system location
(/users/sim/packages). I used the following command to configure clang:
cmake -DCMAKE_C_COMPILER=/users/sim/packages/gcc/4.8.2/bin/gcc
-DCMAKE_CXX_COMPILER=/users/sim/packages/gcc/4.8.2/bin/g++
-DGCC_INSTALL_PREFIX=/users/sim/packages/gcc/4.8.2
-DCMAKE_CXX_LINK_FLAGS="-L/users/sim/packages/gcc/4.8.2/lib64
-Wl,-rpath,/users/sim/packages/gcc/4.8.2/lib64"
-DCMAKE_INSTALL_PREFIX=/users/sim/packages/gcc/4.8.2
-DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_BUILD_TYPE="Release"
-DLLVM_TARGETS_TO_BUILD="X86" ../llvm-3.5.0.src/
That worked fine and it created a working clang++ binary. However, when I
use that to compile a C++ program the executable does not have an rpath
entry pointing to /users/sim/packages/gcc/4.8.2/lib64:
% clang++ test.cpp
% ldd a.out
linux-vdso.so.1 => (0x00007fffd49fd000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003577e00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003571600000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003577600000)
libc.so.6 => /lib64/libc.so.6 (0x0000003571200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003570e00000)
I want to use C++11 features so presumably I do need to use the newer
libstdc++.so library that is installed with gcc 4.8.2. I know I can fix
this by adding -Wl,-rpath,/users/sim/packages/gcc/4.8.2/lib64 to my clang++
command but this shouldn't be necessary. I would like to know if there is
a way to get clang to automatically add these extra linker options when
compiled against a version of gcc installed in a non system location.
I thought this is what the --with-gcc-toolchain option would do (when using
configure rather than cmake) but that didn't seem to work. So far, the
only way I have been able to get it to work is by patching Tools.cpp at
line 7413 in the function gnutools::Link::ConstructJob:
Args.AddAllArgs(CmdArgs, options::OPT_L);
Args.AddAllArgs(CmdArgs, options::OPT_u);
const ToolChain::path_list Paths = ToolChain.getFilePaths();
for (const auto &Path : Paths)
CmdArgs.push_back(Args.MakeArgString(StringRef("-L") + Path));
#if USE_MY_PATCH
CmdArgs.push_back("-rpath");
if (ToolChain.getArch() == llvm::Triple::x86_64)
CmdArgs.push_back("/users/sim/packages/gcc/4.8.2/lib64");
else
CmdArgs.push_back("/users/sim/packages/gcc/4.8.2/lib");
#endif
if (D.IsUsingLTO(Args))
AddGoldPlugin(ToolChain, Args, CmdArgs);
if (Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
CmdArgs.push_back("--no-demangle");
AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs);
but I can't believe there isn't an easier way. If clang is built using a
non-system libstdc++.so library then shouldn't it automatically add the
required -rpath option to use that same library at runtime ?
--
Glenn Coombs
P.S. Please reply to my email address as well as the mailing list as I am
not subscribed to this list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150211/f31f8a04/attachment.html>
More information about the cfe-dev
mailing list