Tom Lane writes:
> >> Er ... what? Why would the test program be trying to use that shlib?
>
> > Because -lssl is added to LIBS, the test program is linked against LIBS,
> > and when the program starts it tries to locate all the dependent libraries
> > (not matter if it doesn't actually have to use them).
>
> Interesting theory, but if LIBS is broken then wouldn't the backend fail
> to run at all? How'd they manage to pass the other regress tests?
Presumably the backend would print an error message along the lines of
"cannot find shared library libxyz.so" and the user would take appropriate
configuration steps. However, this doesn't really help when running
configure because no user actually reads every 'checking...' line and
tries to challenge the result by examining config.log.
The same problem occurs when the backend is run from within initdb to
check the version. If there's a shared library loading problem the
postgres --version invocation will fail and the user will see a misleading
error message. I'm currently changing it to print the backend's stderr if
any was provided, so I now get
$ pg-install/bin/initdb pg-install/var/data
The program
'/home/peter/pg-install/bin/postgres'
needed by initdb does not belong to PostgreSQL version 7.1beta5, or
there may be a configuration problem.
This was the error message issued by that program:
cannot open shared library libxyz.so
(Here I replaced 'postgres' with a simple shell script.)
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
