Re: pgsql 8.0.0b1 - openssl detection

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 previo=
us=20
email).

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


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

ac_cv_build=3Di686-pc-linux-gnu
ac_cv_build_alias=3Di686-pc-linux-gnu
ac_cv_c_compiler_gnu=3Dyes
ac_cv_env_CC_set=3Dset
ac_cv_env_CC_value=3Dgcc
ac_cv_env_CFLAGS_set=3Dset
ac_cv_env_CFLAGS_value=3D$'-O2 -g -I/usr/local/ssl/include'
ac_cv_env_CPPFLAGS_set=3Dset
ac_cv_env_CPPFLAGS_value=3D$'-O2 -g -I/usr/local/ssl/include'


Taking a closer look to configure output I see:

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

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=3D"-D_GNU_SOURCE"

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

CPPFLAGS=3D"$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=3Darg) 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>>