BUG #4219: fseeko test failure in configure script

Nathan Reed wrote:

The following bug has been logged online:

Bug reference: 4219
Logged by: Nathan Reed
Email address: nreed@uci.edu
PostgreSQL version: 8.3.1
Operating system: Sparc Solaris 10 - 08/07 release
Description: fseeko test failure in configure script
Details:

It does not matter what parameters I do or do not provide on the configure
step, I get the same failure every time:
checking for fseeko... (cached) yes
checking test program... failed
configure: error:
Could not execute a simple test program. This may be a problem related to
locating shared libraries. Check the file 'config.log' for the exact
reason.

I have even attempted to re-order the configure.in file to no avail. I
wanted a version with ssl support (sunfreeware.com does not provide a built
version with the ssl support), but this jacked up problem with fseeko is
pushing me to use MySQL because I have been successful in configuring,
making, and installing a version with ssl support. Encryption is critical
in my environment.

what compiler/tool stack are you using? what additional libraries?

for sparc, I'd highly recommend using Sun Studio, aka SUNWspro,
available from sun for free nowdays (installs to /opt/SUNWspro/..., so
put that bin in your path before any other compilers)

"Nathan Reed" <nreed@uci.edu> writes:

It does not matter what parameters I do or do not provide on the configure
step, I get the same failure every time:
checking for fseeko... (cached) yes
checking test program... failed
configure: error:
Could not execute a simple test program. This may be a problem related to
locating shared libraries. Check the file 'config.log' for the exact
reason.

This is not related to fseeko, that just happens to be the test before
the one that is failing. Did you look into config.log to see what is
going wrong?

regards, tom lane

I am using the gcc 3.4.6 compiler. With all of the needed packages
for this config run, I have included the following elements in a script:

#
./configure --with-openssl --with-libxml --with-libxslt
--with-libraries=/usr/local/ssl/lib:/usr/local/BerkeleyDB.4.2/lib
--with-includes=/usr/local/ssl/include:/usr/local/BerkeleyDB.4.2/include

All of the necessary elements came via pkgadd commands with packages
from sunfreeware.com. That site notes the use of gcc 3.4.6 and based
upon a previous debacle with Perl/Apache/MySQL where a mixture of gcc
compiled packages were included in the SUNWspro compiler
configuration and make processes, I don't feel like going through the
inflicted pain of incompatible address spacing with the shared
objects modules. I am aware of the use of the Sun compiler because I
started using it on Solaris 2.6 in 1994.

I have attempted to decipher the config.log, but the messaging in
there leaves me scratching my head because of what is left out. I am
well aware of the shortcomings of make in terms of the messages that
come out, but simple things such as the actual test being run are
obscured at best.

Nathan K. Reed
Programmer/Analyst
Supervisor of Records group
University of California, Irvine
Office of Admissions and Relations with Schools
(949) 824-9631

At 11:47 AM 6/4/2008, John R Pierce wrote:

I looked at the config.log file, but I can only discern that it
appears to be failing on fseeko in the configure section that loops
through tests in the area where there are comments about NetBSD, etc
re-rendering of fseeko. Understanding that make is difficult with
messaging, the output that was in the config.log did not inspire any
confidence in the process.

Nathan K. Reed
Programmer/Analyst
Supervisor of Records group
University of California, Irvine
Office of Admissions and Relations with Schools
(949) 824-9631

At 11:48 AM 6/4/2008, Tom Lane wrote:

Nathan Reed <nreed@uci.edu> writes:

I looked at the config.log file, but I can only discern that it
appears to be failing on fseeko in the configure section that loops
through tests in the area where there are comments about NetBSD, etc
re-rendering of fseeko.

Well, if you don't understand it, consider providing the output
so that someone who does understand can take a look.

FWIW, the last couple hundred lines of config.log are usually not very
helpful for diagnosing failures, because they just represent a dump of
the settings the script was able to figure out before it failed. What
you want to look at is the final test case, which will be right before
this:

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=...

regards, tom lane

[ 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

Tom,
LD_LIBRARY_PATH is the correct env var to use. However, you are
correct that this hamstrings the generated executable - requiring
that the LD_LIBRARY_PATH include all of the shared object libraries
in the rc scripts themselves.

Regarding the possibility of a bug, I had indicated that I
performed the ld command from the command in the postgres build area
and did not have an error returned. Here is the listing of the ssl
lib area (done with pkgadd):

# cd /usr/local/ssl/lib
# ls -l
total 9004
-rwxrwx--x 1 root root 1540 Jun 5 08:49 a.out
drwxr-xr-x 2 bin bin 512 Jun 3 11:15 engines
-rw-r--r-- 1 bin bin 2290290 May 30 02:54 libcrypto.a
lrwxrwxrwx 1 root root 18 Jun 3 11:15 libcrypto.so -> libcrypto.so.0.9.8
-r-xr-xr-x 1 bin bin 1559648 May 30 02:54 libcrypto.so.0.9.8
-rw-r--r-- 1 bin bin 404896 May 30 02:54 libssl.a
lrwxrwxrwx 1 root root 15 Jun 3 11:15 libssl.so -> libssl.so.0.9.8
-r-xr-xr-x 1 bin bin 302776 May 30 02:54 libssl.so.0.9.8
drwxr-xr-x 2 bin bin 512 Jun 3 11:15 pkgconfig

The links are there from libssl to the specific shared object lib and
all of the packages I added were built using the gcc compiler.

Nathan K. Reed
Programmer/Analyst
Supervisor of Records group
University of California, Irvine
Office of Admissions and Relations with Schools
(949) 824-9631

At 09:55 AM 6/5/2008, Tom Lane wrote:

Am Donnerstag, 5. Juni 2008 schrieb Nathan Reed:

LD_LIBRARY_PATH is the correct env var to use. However, you are
correct that this hamstrings the generated executable - requiring
that the LD_LIBRARY_PATH include all of the shared object libraries
in the rc scripts themselves.

From doc/FAQ_Solaris:

"""
3) Why does configure complain about a failed test program?

This is probably a case of the run-time linker being unable to find
some library, probably libz, libreadline or some other non-standard
library such as libssl. To point it to the right location, set the
LDFLAGS environment variable, e.g.,

LDFLAGS="-R /usr/sfw/lib:/opt/sfw/lib:/usr/local/lib"
export LDFLAGS

and restart configure. See the ld(1) man page for more
information.
"""

Does not change anything. I have run the generic configure without
any parameters (--with-ssl, etc) and I get the same result. I have
done a number of permutations, made sure that bison is in place,
etc,etc,etc. I am not getting beyond this linker failure on the test
of fseeko and I can run the ld command from the command line in the
postgres directory context (pointing at the library for ssl that is
not opening in postgres configure) and not have an open error
returned. I need the ssl encryption capabilities and the only way to
enable this functionality is at the configure step. If the Configure
script cannot work to provide me this crucial part of the
implementation, postgres has no value for my office. I have been
able to successfully build MySQL with similar parameter needs
implementing openssl. That also uses the configure methodology I
don't buy into the bug in Solaris and or that the SUNWspro compiler
should be used. If fact, for the packages that I use from
Sunfreeware.com, the gcc 3.4.6 compiler is used for that work and not
the Sun compiler. I have seen the shared object address space issues
that arise from this compiler incompatibility.

I noticed that the config sub-directory uses m4 macro files. Is
there something related to this area that I need to consider. For
instance, upgrading M4?

Nathan K. Reed
Programmer/Analyst
Supervisor of Records group
University of California, Irvine
Office of Admissions and Relations with Schools
(949) 824-9631

At 04:50 AM 6/6/2008, Peter Eisentraut wrote:

Am Freitag, 6. Juni 2008 schrieb Nathan Reed:

Does not change anything. �I have run the generic configure without
any parameters (--with-ssl, etc) and I get the same result. �I have
done a number of permutations, made sure that bison is in place,
etc,etc,etc.

Trying countless permutations of unrelated parameters is not going to get you
closer to success. And neither is posting generic "I am not getting beyond
this linker failure on the test of fseeko" error "descriptions" that have
nothing to do with your problem. If you want to get any useful help, post
your *exact* command line, and the *exact* output you get on the screen as
well as the *complete* contents of files that the error message refers you
to. And leave the interpretation to others. As far as I can tell, the
problem you post is quite common on Solaris, but without any concrete
information, I can't tell you how to fix it.

I have finally gotten cleanly through the configure step. The
documentation for postgres under section 15.5 gives the various
options, one of which is the --with-libraries. This option does not
seem to work correctly for Solaris 10 with various packages added
into /usr/local and /usr/local/ssl. A previous response indicated
that the use of LDFLAGS would solve this. However, the documentation
in section 15.5 does not give any indications or hisnts about what
types of usage are possible. Thus, the suggestion for putting in the
following as a template:
"-R /usr/local/lib:/usr/sfw/lib..." was the ticket. Thus, my script
is as follows:

./configure
--with-openssl
--with-libxml
--with-libxslt
--with-libraries=/usr/lib:/usr/local/ssl/lib:/usr/sfw/lib:
/usr/local/BerkeleyDB.4.2/lib:/usr/ccs/lib:/usr/ucblib
--with-includes=/usr/local/ssl/include:/usr/sfw/include:
/usr/local/BerkeleyDB.4.2/include
LDFLAGS='-R /usr/local/lib:/usr/local/ssl/lib:/usr/sfw/lib:
/usr/local/BerkeleyDB.4.2/lib:/usr/ccs/lib:/usr/ucblib'

++++++++++++++++

The pertinent ENV vars are:

HOSTTYPE=sun4
PATH=/usr/local/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/usr/ccs/bin
PWD=/u1/installs/postgresql-8.3.1
JAVA_HOME=/usr/java
TZ=US/Pacific
PS1=#
SHLVL=2
OSTYPE=solaris
VENDOR=sun
MACHTYPE=sparc

++++++++++++++++++

All of the necessary components with dependencies were brought in
from sunfreeware and installed with pkgadd.
gcc=3.4.6 as the compiler and primary libgcc.

Nathan K. Reed
Programmer/Analyst
Supervisor of Records group
University of California, Irvine
Office of Admissions and Relations with Schools
(949) 824-9631

At 08:56 AM 6/6/2008, Peter Eisentraut wrote: