[ please keep the mailing list cc'd ]
Nathan Reed <nreed@uci.edu> writes:
> Here is the dump of the config.log file in the pertinent area:
> configure:19839: checking test program
> configure:19854: gcc -o conftest -O2 -Wall -Wmissing-prototypes
> -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels
> -fno-strict-aliasing
> -fwrapv -I/usr/local/include/libxml2 -I/usr/local/ssl/include
> -I/usr/local/BerkeleyDB.4.2/include -L/usr/local/lib -L/usr/lib
> -L/usr/local/ssl/lib -L/usr/local/BerkeleyDB.4.2/lib -L/usr/ccs/lib
> -L/usr/ucblib conftest.c -lxslt -lxml2 -lssl -lcrypto -lz -lreadline
> -ltermcap -lrt -lsocket -lm >&5
> configure:19857: $? = 0
> configure:19859: ./conftest
> ld.so.1: conftest: fatal: libssl.so.0.9.8: open failed: No such file
> or directory
> ./configure: line 19860: 641 Killed ./conftest$ac_exeext
> configure:19862: $? = 137
> configure: program exited with status 137
Personally I would argue that this is a bug in your operating system ;-)
What is happening is that the generated object file just references
"libssl.so.0.9.8" without any memory of where it had been found at
link time, and if the dynamic linker doesn't search all the same
directories as you had -L switches for, you lose.
One workaround is to set LD_LIBRARY_PATH (or perhaps LD_RUN_PATH, but
never having worked on Solaris I'm not too sure which). This isn't
very desirable because you'd have to do the same whenever invoking
Postgres programs. It'd be better to alter the dynamic linker's
configuration to make sure it searches all of your nonstandard library
locations, or if you can't do that move all your libraries into the
standard directories.
regards, tom lane