--nextPart2361372.QitzzXJfI9
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

--nextPart2361372.QitzzXJfI9
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBIlhkVEjwdyuhmSoRAi8/AJ461rcbxZzJCPPVLVFqbnXITqiS2wCcCwH2
R51KZddUeEURy5XV5tvlyxU=
=P1zs
-----END PGP SIGNATURE-----

--nextPart2361372.QitzzXJfI9--

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

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


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Stefanos Harhalakis wrote:
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.

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/


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

--nextPart45539394.J0JpPDvRx7
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 August 2004 20:14, Peter Eisentraut wrote:
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>>

--nextPart45539394.J0JpPDvRx7
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBI6SNVEjwdyuhmSoRAnMCAJ94hWm8tNLUoHbkS+qeYS UMJIpFoACeIPji
GN71LQCUqCrY28VUs2jSyio=
=c7AQ
-----END PGP SIGNATURE-----

--nextPart45539394.J0JpPDvRx7--

--nextPart1948367.Q6xuZ4gynn
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Wednesday 18 August 2004 23:09, Peter Eisentraut wrote:
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.

You're right. Please ignore my ignorance

<<V13>>

--nextPart1948367.Q6xuZ4gynn
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBI8C2VEjwdyuhmSoRAqt+AJ955i19epGubUoS+IOAin BaCq86eQCggY2Z
rfsAeDeMd8CBC2G3Hs4wWk8=
=8U//
-----END PGP SIGNATURE-----

--nextPart1948367.Q6xuZ4gynn--

Stefanos Harhalakis <v13 (AT) it (DOT) teithe.gr> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

--nextPart1259531.vCbA8j80sk
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Friday 20 August 2004 03:52, Tom Lane wrote:
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>>

--nextPart1259531.vCbA8j80sk
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBJhgjVEjwdyuhmSoRAoHHAKCDILWv7SpvcNpvwTRdMn SP7MOeNwCgoTbY
hSdSKMGW0U9k+p5NnTgd4No=
=gqaB
-----END PGP SIGNATURE-----

--nextPart1259531.vCbA8j80sk--