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

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 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.
>"""