From: David R. M. <dr...@fi...> - 2011-04-14 15:16:23
|
On Apr 13, 2011, at 7:32 PM, <jb...@ac...> wrote: > From: Mark Perley [mailto:mpe...@gm...] >> [dba@clnvirt4-/usr/local/lib] >> -rwxr-xr-x 1 root system 116298 Apr 09 13:59 libz.so.1.2.5 > > Can you run *any* program linked against this? Check this one out: > > #include <zlib.h> > #include <stdio.h> > int main(void) { > printf("%s\n", zlibVersion()); > return 0; > } > > Compile it thus: > > gcc -o foo foo.c /usr/local/lib/libz.so.1.2.5 > > Make sure it runs and outputs the correct zlib version (the one from, I guess, /usr/local/include/zlib.h) (You can also verify you got the correct zlib using the program ldd, but the above compile/link should be proof against any search path weirdness.) > > Assuming that this does work (if it doesn't you probably have an LD_LIBRARY_PATH problem), then you apparently have a libtool problem. This might fix it: > > make maintainer-clean > ./autogen.sh > ./configure > make check > > If it does we need to do some more work to find out why Glenn's chosen libtool and the Mac OS one are out of step. > This doesn't look like Mac OS X to me, since the suffix used in the OP's message was .so and not .dyld . Also, in the case of OS X the path problem would be in DYLD_LIBRARY_PATH (although due to a major difference between OS X and Linux in the way library paths are resolved, a more appropriate variable is usually DYLD_FALLBACK_LIBRARY_PATH). -- Dave |