`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 <dbn.li...@gmail.com> wrote: > On Thu, Dec 16, 2010 at 5:39 PM, Bruce Korb <bruce.k...@gmail.com> 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? > > -- > Dan > _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool