pgsql 8.0.0b1 - openssl detection

Stefanos Harhalakis wrote:

It seems that you've removed the possibility to add an argument to
--with-openssl option of the configure script. Currently I'm
maintaining two systems where the openssl is not somewhere in the
standard paths and thus the only way to compile with SSL seems to be
by setting appropriate CFLAGS, CXXGLAGS and LDFLAGS before running
the configure script.

Yes, that's the standard way to go about it. No need to duplicate that
functionality.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Wednesday 18 August 2004 20:14, Peter Eisentraut wrote:

Stefanos Harhalakis wrote:

It seems that you've removed the possibility to add an argument to
--with-openssl option of the configure script. Currently I'm
maintaining two systems where the openssl is not somewhere in the
standard paths and thus the only way to compile with SSL seems to be
by setting appropriate CFLAGS, CXXGLAGS and LDFLAGS before running
the configure script.

Yes, that's the standard way to go about it. No need to duplicate that
functionality.

Well, in fact, setting:

export CFLAGS="-O2 -g -I/usr/local/ssl/include"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-L/usr/local/ssl/lib"

didn't work at all. It worked only when I did:

export CC="gcc -I/usr/local/ssl/include -L/usr/local/ssl/lib"
export CXX="g++ -I/usr/local/ssl/include -L/usr/local/ssl/lib"
(not sure if CXX is required)

or

export CFLAGS="-O2 -g -I/usr/local/ssl/include"
export CXXFLAGS="$CFLAGS"
export LDFLAGS="-L/usr/local/ssl/lib"
export CPP="gcc -E -I/usr/local/ssl/include"

This happens because AC_CHECK_HEADERSis implemented using the preprocessor
(cpp/gcc -E) without adding CFLAGS/CXXFLAGS:

configure:
----------
checking for SSL_library_init in -lssl... yes
[...]
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... no
configure: WARNING: openssl/ssl.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: openssl/ssl.h: proceeding with the preprocessor's result
checking for openssl/ssl.h... no

config.log:
-----------
configure:8492: checking openssl/ssl.h presence
configure:8499: gcc -E -D_GNU_SOURCE conftest.c
configure:8495:25: openssl/ssl.h: No such file or directory
configure:8505: $? = 1
configure: failed program was:
#line 8494 "configure"
#include "confdefs.h"
#include <openssl/ssl.h>
configure:8523: result: no
configure:8529: WARNING: openssl/ssl.h: accepted by the compiler, rejected by
the preprocessor!
configure:8531: WARNING: openssl/ssl.h: proceeding with the preprocessor's
result
configure:8541: checking for openssl/ssl.h
configure:8548: result: no
configure:8555: error: header file <openssl/ssl.h> is required for OpenSSL

If you are not going to change this back to the old behaviour you should
consider using AC_ARG_ENABLE instead of AC_ARG_WITH since the second is
intended to be used when there is an optional (or not) argument to be passed
(--with-package=arg) while the first is intended to be used to enable or
disable a feature (--enable-feature).

I believe that it makes sense to say 'enable ssl support', since you're not
allowing the user to specify the openssl location. (just a suggestion)

<<V13>>

Stefanos Harhalakis wrote:

This happens because AC_CHECK_HEADERSis implemented using the
preprocessor (cpp/gcc -E) without adding CFLAGS/CXXFLAGS:

The correct variable is CPPFLAGS. Actually, you can also use
--with-includes, but this is only in PostgreSQL, so I suggest you get
used to CPPFLAGS, because that works everywhere.

If you are not going to change this back to the old behaviour you
should consider using AC_ARG_ENABLE instead of AC_ARG_WITH since the
second is intended to be used when there is an optional (or not)
argument to be passed (--with-package=arg) while the first is
intended to be used to enable or disable a feature
(--enable-feature).

This is wrong. Both variants can accept an argument or not. The
difference is only in the spelling.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Wednesday 18 August 2004 23:09, Peter Eisentraut wrote:

Stefanos Harhalakis wrote:

This happens because AC_CHECK_HEADERSis implemented using the
preprocessor (cpp/gcc -E) without adding CFLAGS/CXXFLAGS:

The correct variable is CPPFLAGS. Actually, you can also use
--with-includes, but this is only in PostgreSQL, so I suggest you get
used to CPPFLAGS, because that works everywhere.

I've tested it with CPPFLAGS too without success (before sending the previous
email).

checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... no
configure: WARNING: openssl/ssl.h: accepted by the compiler, rejected by the
preprocessor!
configure: WARNING: openssl/ssl.h: proceeding with the preprocessor's result
checking for openssl/ssl.h... no

config.log:
===========
## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-pc-linux-gnu
ac_cv_build_alias=i686-pc-linux-gnu
ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=set
ac_cv_env_CC_value=gcc
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value=$'-O2 -g -I/usr/local/ssl/include'
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=$'-O2 -g -I/usr/local/ssl/include'

Taking a closer look to configure output I see:

checking for egrep... grep -E
configure: using CPPFLAGS=-D_GNU_SOURCE
configure: using LDFLAGS=-L/usr/local/ssl/lib
checking for gawk... gawk

It seems that the problem is in src/template/linux:

$ cat src/template/linux
# Force _GNU_SOURCE on; plperl is broken with Perl 5.8.0 otherwise
CPPFLAGS="-D_GNU_SOURCE"

which is beeing sourced by configure.in. Changing this to

CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"

solves the problem.

If you are not going to change this back to the old behaviour you
should consider using AC_ARG_ENABLE instead of AC_ARG_WITH since the
second is intended to be used when there is an optional (or not)
argument to be passed (--with-package=arg) while the first is
intended to be used to enable or disable a feature
(--enable-feature).

This is wrong. Both variants can accept an argument or not. The
difference is only in the spelling.

You're right. Please ignore my ignorance :)

<<V13>>

Stefanos Harhalakis <v13@it.teithe.gr> writes:

It seems that the problem is in src/template/linux:

$ cat src/template/linux=20
# Force _GNU_SOURCE on; plperl is broken with Perl 5.8.0 otherwise
CPPFLAGS="-D_GNU_SOURCE"

which is beeing sourced by configure.in. Changing this to
CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
solves the problem.

Hmm, good point (and I see template/hpux is committing the same sin).

For CFLAGS, configure.in takes pains to not let the template file
override a user-supplied setting. Should we do the same for CPPFLAGS,
or just apply the quick-and-dirty patch suggested by Stefanos to these
two templates?

regards, tom lane

On Friday 20 August 2004 03:52, Tom Lane wrote:

Stefanos Harhalakis <v13@it.teithe.gr> writes:

It seems that the problem is in src/template/linux:

$ cat src/template/linux=20
# Force _GNU_SOURCE on; plperl is broken with Perl 5.8.0 otherwise
CPPFLAGS="-D_GNU_SOURCE"

which is beeing sourced by configure.in. Changing this to
CPPFLAGS="$CPPFLAGS -D_GNU_SOURCE"
solves the problem.

Hmm, good point (and I see template/hpux is committing the same sin).

For CFLAGS, configure.in takes pains to not let the template file
override a user-supplied setting. Should we do the same for CPPFLAGS,
or just apply the quick-and-dirty patch suggested by Stefanos to these
two templates?

I believe that if someone shall have to set CPPFLAGS="-I..." for openssl then
he should not have to guess that CPPFLAGS should also contain -D_GNU_SOURCE,
unless it is stated in the documentation or as a warning when running the
configure script.

<<V13>>