On Wed, Jun 11, 2003 at 04:16:56PM +0100, Lars Hecking wrote: > On Solaris prior to release 8, the proper linker flags must be specified > to enable the linker to find the correct runtime libraries. Either via > -R/usr/local/lib, or LD_RUN_PATH=/usr/local/lib in the environment.
LD_LIBRARY_PATH is needed when linking. So can someone explain why gcc is able to build a program with -lz but not ld? I never thought about it, but I assumed gcc called ld when linking. If that's the case then gcc is calling a different linker than the one libtool is using to built my library. The basic problem is that configure with AC_CHECK_LIB says the libz library can be used, but then it fails when trying to actually build with the library. I'm using Automake and Libtool. Perhaps it's libtool that is setting up the wrong linker to use? My build uses libtool to build both a library and a binary. I cannot build the library without LD_LIBRARY_PATH, but I can build the binary. In other words, using gcc works, but calling ld directly does not. So: this works to build the binary without the need for LD_LIBRARY_PATH: /bin/ksh ../libtool --mode=link gcc -g -O2 -o swish-e swish.o keychar_out.o dump.o result_output.o libswishindex.la libswish-e.la -lm gcc -g -O2 -o .libs/swish-e swish.o keychar_out.o dump.o result_output.o ./.libs/libswishindex.al -L/data/_g/lii/local/lib /data/_g/lii/local/lib/libxml2.so -L/usr/local/lib -lsocket -lnsl ./.libs/libswish-e.so -lz -lm -R/data/_g/lii/local/lib -R/usr/local/lib But buidling the library where libtool uses /usr/ccs/bin/ld directly doesn't: /bin/ksh ../libtool --mode=link gcc -g -O2 -o libswish-e.la -rpath /usr/local/lib -version-info 2:0:0 -lz search.lo swish2.lo swish_words.lo proplimit.lo rank.lo db_read.lo result_sort.lo hash.lo compress.lo db_native.lo ramdisk.lo check.lo error.lo list.lo mem.lo swstring.lo docprop.lo metanames.lo headers.lo swish_qsort.lo date_time.lo double_metaphone.lo stemmer.lo soundex.lo replace/libreplace.la snowball/libsnowball.la -lm rm -fr .libs/libswish-e.la .libs/libswish-e.* .libs/libswish-e.* /usr/ccs/bin/ld -G -h libswish-e.so.2 -o .libs/libswish-e.so.2.0.0 search.lo swish2.lo swish_words.lo proplimit.lo rank.lo db_read.lo result_sort.lo hash.lo compress.lo db_native.lo ramdisk.lo check.lo error.lo list.lo mem.lo swstring.lo docprop.lo metanames.lo headers.lo swish_qsort.lo date_time.lo double_metaphone.lo stemmer.lo soundex.lo -z allextract replace/.libs/libreplace.al snowball/.libs/libsnowball.al -z defaultextract -lz -lm -lc ld: fatal: library -lz: not found Using LD_LIBRARY_PATH adds to the search path used by ld, which is a fix. So, is it autotools (libtool) that is using the wrong linker to build the library? Or is my installation of solaris broken because gcc and ld have different compiled-in search paths? I suspect it's my installation, but then I wonder what linker gcc is using that works. Sorry for my ignorance, but thanks to Autotools I don't normally have to think about these things! Thanks, -- Bill Moseley [EMAIL PROTECTED] _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
