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
