Thread: pgsql 8.0.0b1 - openssl detection
Hi there... I'm trying to compile pgsql 8.0.0b1. It seems that you've removed the possibility to add an argument to=20 --with-openssl option of the configure script. Currently I'm maintaining tw= o=20 systems where the openssl is not somewhere in the standard paths and thus t= he=20 only way to compile with SSL seems to be by setting appropriate CFLAGS,=20 CXXGLAGS and LDFLAGS before running the configure script. I believe that there may be other people out there with similar systems, = so=20 you may consider reverting this change back... Thanks in advance,=20 <<V13>>
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/
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 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=3D"-O2 -g -I/usr/local/ssl/include" export CXXFLAGS=3D"$CFLAGS" export LDFLAGS=3D"-L/usr/local/ssl/lib" didn't work at all. It worked only when I did: export CC=3D"gcc -I/usr/local/ssl/include -L/usr/local/ssl/lib" export CXX=3D"g++ -I/usr/local/ssl/include -L/usr/local/ssl/lib"=20 (not sure if CXX is required) or export CFLAGS=3D"-O2 -g -I/usr/local/ssl/include" export CXXFLAGS=3D"$CFLAGS" export LDFLAGS=3D"-L/usr/local/ssl/lib" export CPP=3D"gcc -E -I/usr/local/ssl/include" This happens because AC_CHECK_HEADERSis implemented using the preprocessor= =20 (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 th= e=20 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: $? =3D 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=20 the preprocessor! configure:8531: WARNING: openssl/ssl.h: proceeding with the preprocessor's= =20 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=20 consider using AC_ARG_ENABLE instead of AC_ARG_WITH since the second is=20 intended to be used when there is an optional (or not) argument to be passe= d=20 (--with-package=3Darg) while the first is intended to be used to enable or= =20 disable a feature (--enable-feature).=20 I believe that it makes sense to say 'enable ssl support', since you're not= =20 allowing the user to specify the openssl location. (just a suggestion) <<V13>>
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>>
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=3D20 > > # 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 > > CPPFLAGS=3D"$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=3D"-I..." for openssl = then=20 he should not have to guess that CPPFLAGS should also contain -D_GNU_SOURCE= ,=20 unless it is stated in the documentation or as a warning when running the= =20 configure script. <<V13>>