Skip site navigation (1) Skip section navigation (2)

Re: BUG #4219: fseeko test failure in configure script

From: Nathan Reed <nreed(at)uci(dot)edu>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-bugs(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, nreed(at)uci(dot)edu
Subject: Re: BUG #4219: fseeko test failure in configure script
Date: 2008-06-06 15:35:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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, 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
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 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

In response to


pgsql-bugs by date

Next:From: Peter EisentrautDate: 2008-06-06 15:56:57
Subject: Re: BUG #4219: fseeko test failure in configure script
Previous:From: Peter EisentrautDate: 2008-06-06 11:50:15
Subject: Re: BUG #4219: fseeko test failure in configure script

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group