Ian Lance Taylor <iant <at> google.com> writes: > > 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 > > Thanks for responding. Actually, you can ignore this post as this was clearly a "user error". I found the cause of my problem. In my main script that builds my entire tool chain, I had been using "readlink" to determine the path to the newer GCC and create the run path to pass to the linker. When I fixed that, the problem disappeared. Thanks anyway !
