[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruce Korb
Subject: Re: How does one specify linking to 64 bit libraries when there is a choice?
Date: Fri, 17 Dec 2010 00:14:30 -0800

`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.

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.

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/ \
>>>  ../snprintfv/ -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/ \
>>>  ../snprintfv/.libs/libsnprintfv.a \
>>>  -L/usr/local/lib /usr/local/lib64/ -L/usr/local/lib64 \
>>>  /usr/local/lib64/ \
>>>  /usr/local/lib/ -lcrypt /usr/local/lib/ \
>>>  -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/
>> Not good:
>>> /usr/local/lib/ 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?
> --
> Dan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]