Re: How does one specify linking to 64 bit libraries when there is a choice?

[Ingo Krabbe]

On Fri, Dec 17, 2010 at 12:14:30AM -0800, Bruce Korb wrote:
> `guile-config link` yields that string.  In fact, it yields:
> 
> > -L/usr/local/lib -lguile -lltdl -L/usr/local/lib64  -lgmp -lcrypt -lm 
> > -lltdl -lm -ldl
> 
> NOTE: " -Wl,-rpath,/usr/local/lib64 " gets inserted some how.

Though rpath is added automatically to the library search path by some
linkers (at least I dimly remember such behaviour), that flag is
dedicated to link loader at run time.

> 
> Also, I thought the -L options were searched most recent to oldest,
> but I am likely forgetting.  In any case, how come it got expanded to a
> full path when it was not a full path in the original set of arguments?
> By expanding the path, it is perforce overriding the actions of the
> linker, even if the linker were to do the same thing.  Seems suspicious
> to me.
> 

Actually, with include paths, link paths and any other path definitions
I can think of it is the first one that rules.

There might be some complex reasons, why libtool decides to use the full
path name but it should be the same the linker would choose.  So, as you
have /usr/local/lib in your paths list, before /usr/local/lib64, the
libraries found there would be used in any case, which seems to be wrong
at your system.

Actually on most 64bit Systems I know, the plain lib/ paths are links to
lib64/, where lib32/ contains the 32bit libs.

However you choose to solve your problem, it might be best to find out,
why your Software uses /usr/local/lib/ at all.




> 
> 
> On Thu, Dec 16, 2010 at 9:39 PM, Dan Nicholson <address@hidden> wrote:
> > On Thu, Dec 16, 2010 at 5:39 PM, Bruce Korb <address@hidden> wrote:
> >>
> >> Here is the problem:
> >>
> >>> /bin/sh ../libtool --tag=CC   --mode=link gcc -std=gnu99 
> >>> -I/usr/local/include \
> >>>   -pthread -g -O2 -export-dynamic  -o autogen  autogen-ag.o 
> >>> ../autoopts/libopts.la \
> >>>  ../snprintfv/libsnprintfv.la -pthread \
> >>>  -L/usr/local/lib -lguile -lltdl \
> >>>  -L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64 \
> >>>  -lgmp -lcrypt -lm -lltdl -lm -ldl
> >>
> >> It looks like things might be okay because "-lgmp" is called out
> >> after the -L/usr/local/lib64 option, but the emitted link fails:
> >>
> >>> libtool: link: gcc -std=gnu99 -I/usr/local/include -pthread -g -O2 \
> >>>  -o .libs/autogen autogen-ag.o -pthread -Wl,-rpath -Wl,/usr/local/lib64 \
> >>>  -Wl,--export-dynamic  ../autoopts/.libs/libopts.so \
> >>>  ../snprintfv/.libs/libsnprintfv.a \
> >>>  -L/usr/local/lib /usr/local/lib64/libguile.so -L/usr/local/lib64 \
> >>>  /usr/local/lib64/libltdl.so \
> >>>  /usr/local/lib/libgmp.so -lcrypt /usr/local/lib/libltdl.so \
> >>>  -lm -ldl -pthread -Wl,-rpath -Wl,/u/guest/bkorb/_i/lib \
> >>>  -Wl,-rpath -Wl,/usr/local/lib64 -Wl,-rpath -Wl,/usr/local/lib
> >>
> >> notice that libgmp is now specified as .../lib/libgmp.so.
> >> Not good:
> >>
> >>> /usr/local/lib/libgmp.so: could not read symbols: File in wrong format
> >>> collect2: ld returned 1 exit status
> >>
> >> /usr/local/lib does not actually contain *ANY* 64 bit objects.
> >> Grepping through the build directory "libtool" script does not
> >> identify any direct reference to that directory, though it does
> >> reference /usr/local/lib64 directly.  So, what is amiss?
> >> How does libtool get screwed up? How to fix it?
> >
> > -L/usr/local/lib is coming first, though, and libtool is respecting
> > the path setup by successive -L options. Who's responsible for adding
> > -L/usr/local/lib?
> >

bye ingo