order of -L options created by gcc for the linker

[tjevon]

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.

In particular, if I specify -Wl,-L/usr/local/ext/lib in the line passed to gcc, the resultant ld command will have the default location of libraries for gcc prior to my -L/usr/local/ext/lib entry. As a result, the linker trys to link older libraries and fails.

In contrast, if I specify -L/usr/local/ext/lib in the line passed to gcc (no -Wl), the resultant ld command will have -L/usr/local/ext/lib prior to the gcc default library location and the link proceeds without error.

Why is this? I thought gcc would take any -Wl specified option and pass it straight on to ld, I wasn't expecting a different placement within the resultant command line.

This is causing a problem for me because our current build environment does not support a method for generating the -L without -Wl.

Are there other arguments that can be passed to gcc so that my -L path is before the compilers?

Any help in understanding this would be appriciated.

[Andrew Haley-5]

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.
 >
 > In particular, if I specify -Wl,-L/usr/local/ext/lib in the line passed to
 > gcc, the resultant ld command will have the default location of libraries
 > for gcc prior to my -L/usr/local/ext/lib entry. As a result, the linker trys
 > to link older libraries and fails.a
 >
 > In contrast, if I specify -L/usr/local/ext/lib in the line passed to gcc (no
 > -Wl), the resultant ld command will have -L/usr/local/ext/lib prior to the
 > gcc default library location and the link proceeds without error.
 >
 > Why is this? I thought gcc would take any -Wl specified option and pass it
 > straight on to ld, I wasn't expecting a different placement within the
 > resultant command line.
 >
 > This is causing a problem for me because our current build environment does
 > not support a method for generating the -L without -Wl.
 >
 > Are there other arguments that can be passed to gcc so that my -L path is
 > before the compilers?
 >
 > Any help in understanding this would be appriciated.

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.

[tjevon]

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