This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Need Help Setting Runpaths For GCC Libraries
- From: Kris Wempa <Kristofer dot Wempa at sig dot com>
- To: gcc-help at gcc dot gnu dot org
- Date: Mon, 28 Oct 2013 20:20:42 +0000 (UTC)
- Subject: Need Help Setting Runpaths For GCC Libraries
- Authentication-results: sourceware.org; auth=none
I am trying to build and deploy a set of tools built with gcc-4.8.1 on a
Linux operating system that already has gcc 4.3.4 installed (SLES11). I am
able to successfully build all of the tools. However, the linker is doing
something with the runpath that I do not want it to do. For any GCC
libraries such as libstdc++, libgcc_s and libgomp, the runpath built into the
executables has a true path rather than the symbolic link we use. For
example, we build and install all of our tools into â/optâ, but /opt is
really a link to /{server name}. So, whatâs happening is that the built
tools only work properly on the machine where I do the builds. On other
machines, since the /{build server}/opt directory does not exist, the tools
pick up the system libraries in /usr/lib64 and subsequently fail. I notice
that this behavior ONLY happens for libraries that are part of gcc. For
other tools, they do not expand the â/optâ link and therefore work properly
on all machines. How can I tell GCC to NOT expand this symbolic link when
itâs linking its own libraries ? I know I can fix this by changing my build
machine so that /opt is not a symbolic link, but I figured that there must be
a way to control this through gcc and/or the linker. Any help would be
appreciated. Thanks in advance.
Kris Wempa