This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need Help Setting Runpaths For GCC Libraries


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 !



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]