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: order of -L options created by gcc for the linker




Andrew Haley-5 wrote:
> 
> tjevon writes:
>  > 
>  > I'm having a problem with gcc placing the default gcc libraries 
>  > (-L/usr/lib/gcc/x86_64-redhat-linux/3.4.5) ahead of the correct (newer)
>  > versions in the list of arguments being passed to ld. 
>  > 
>  
> This doesn't make any sense.  gcc always links the versions of the
> libraries that are compatible with the gcc version that's installed.
> If you have a newer version of gcc installed, with newer libraries,
> the new gcc will link against the new libraries.
> 
> I find it hard to imagine what kind of a broken setup would give the
> problems you're describing.
> 
> Andrew
> 

Maybe I should have been more specific about which libraries I'm having
trouble with. There is a version of gtk+ that is part of the linux (redhat)
distribution installed in /usr/lib64. There is a more recent version
available that I installed in /usr/local/ext/lib. 

The problem I'm having isn't directly caused by my installation or my build
environment. The problem is that when gcc formats the line used by ld, it's
placing -L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../lib64 before
the -L/usr/local/extlib that I pass to the gcc (using -Wl,) for the link. As
a result, the incorrect gtk+ library is being used for the link.

so the command that my build environment executes is similar to:
/usr/bin/g++ foo.o -o foo -Wl,-R/usr/local/ext/lib
-Wl,-L/usr/local/ext/lib -Wl,-R/usr/X11R6/lib64 -Wl,-L/usr/X11R6/lib64
-lgtkmm ... -lgtk-x11-2.0 ...

I left out all the other require libraries for brevity.

The line that g++ creates for the link has
-L/usr/lib/gcc/x86_64-redhat-linux/3.4.5/../../../../lib64 (location not
specified by me, but by gcc) before the -L/usr/local/ext/lib. I determined
this by adding a -v argument.

If I change the line passed to g++ to: (please notice that I've removed the
-Wl, preceeding my lib location)
/usr/bin/g++ foo.o -o foo -Wl,-R/usr/local/ext/lib -L/usr/local/ext/lib
-Wl,-R/usr/X11R6/lib64 -Wl,-L/usr/X11R6/lib64 -lgtkmm ... -lgtk-x11-2.0 ...

the line that g++ creates for the link has -L/usr/local/ext/lib before the
gcc generated -L/usr/lib/gcc/x86_64-redhat-linkux/3.4.5/../../../../lib64.

What I was surprised at was the resultant different location in the link
command for my -L/usr/local/ext/lib as a result of using -Wl,. I was looking
for an explaination of this behavior and/or a way to insure that my -L would
preceed any -L inserted into the link command by gcc. 

The obvious way would be to just use the -L instead of -Wl. Unfortunately,
this is where my build environment enters the picture. There is currently
(may need to change) no way to have it generate a -L instead of the -Wl,-L.

After rereading my original, I realize I should have said "problem with gcc
placing the default gcc library locations (-L(s)), ahead of my specified -L.

tjevon
-- 
View this message in context: http://www.nabble.com/order-of--L-options-created-by-gcc-for-the-linker-tf3978436.html#a11305923
Sent from the gcc - Help mailing list archive at Nabble.com.


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