Re: Library path with AC_CHECK_LIB

[Bill Moseley]

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
address@hidden