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
