On Mon, Oct 28, 2013 at 1:20 PM, Kris Wempa <Kristofer.Wempa@xxxxxxx> wrote:
> 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.
What you are describing sounds strange to me.
The GNU/Linux linker does not normally record the runpath of any
shared library at all. A shared library normally has a DT_SONAME
dynamic tag; you can see this by running readelf -d on the shared
library and grepping for SONAME. When you link against the shared
library, the linker will record the SONAME in the binary as a
DT_NEEDED tag.
The runpath is set by linker options like -R, not by the shared
libraries.
So to answer your specific question, there is no way to tell GCC to
not expand the symbolic link, because it doesn't do so anyhow.
Perhaps you could show us some specific command lines, including the
output, to show the problem that you are seeing. Because my best
guess is that you are misinterpreting something.
Ian
