Thread: configure: error: header file is required for
OpenSSL
I'm trying to compile 7.2.1 on Red Hat 7.2: [root@cayman postgresql-7.2.1]# ./configure --enable-locale --enable-multibyte=LATIN1 --with-tcl --enable-odbc --with-openssl=/usr/share/ssl --with-java <snip> checking for openssl/ssl.h... yes checking for openssl/err.h... no configure: error: header file <openssl/err.h> is required for OpenSSL But this makes no sense: [root@cayman openssl]# rpm -qf /usr/include/openssl/ssl.h openssl-devel-0.9.6b-8 [root@cayman openssl]# rpm -qf /usr/include/openssl/err.h openssl-devel-0.9.6b-8 And: [root@cayman openssl]# rpm -qa |grep openssl openssl095a-0.9.5a-11 openssl-devel-0.9.6b-8 openssl-perl-0.9.6b-8 openssl-0.9.6b-8 What am I doing wrong? -- Peter Peltonen System Administrator Fivetec Solutions Oy Melkonkatu 28 E 00210 Helsinki GSM. +358-40 720 6535 Tel. +358-9-6824 7666 Fax. +358-9-6824 7664 http://www.fivetec.com mailto:peter.peltonen@fivetec.com --
On Mon, 2002-04-22 at 10:54, Jean-Michel POURE wrote: > Le Lundi 22 Avril 2002 09:23, Peter Peltonen a écrit : > > --enable-multibyte=LATIN1 > > 1) Multibyte > > Latin1 is not a multi-byte character. This is not the way to create a Latin1 > database. Creating a Latin1 database is done by CREATE DATABASE foo WITH > ENCODING = "Latin1". Anyway, it is now recommanded to use Latin9 (Latin1 + > euro support) instead of Latin1. Thanks for the Latin9 tip. But about Multibyte, quoted from http://www2.se.postgresql.org/users-lounge/docs/7.1/admin/multibyte.html --<snip>-- 5.2.1. Enabling MB Run configure with the multibyte option: % ./configure --enable-multibyte[=encoding_system] where encoding_system can be one of the values in the following table: --</snip>-- and LATIN1 is mentioned as a valid encoding_system. I thought I was just following documentation. This was for 7.1, though -- has this functionality been changed in 7.2? > Why don't you simply --enable-multibyte? Then, you will be able to create a > Latin1, Latin9 (=Latin1+euro) or Unicode database. PostgreSQL offers > automatic recoding between server and client using SET CLIENT_ENCODING = > "Latin9". I assume that the encoding_system given as a parameter to --enable-multibyte just sets the _default_ encoding system used by PostgreSQL when creating db's with initdb. From the same documentation: --<snip>-- Here is an example of configuring Postgres to use a Japanese encoding by default: % ./configure --enable-multibyte=EUC_JP If the encoding system is omitted (./configure --enable-multibyte), SQL_ASCII is assumed. --</snip>-- Or have I misundestood the docs? > 2) RPMs > If you are new to PostgreSQL, why don't you install RPMs? They can be > downloaded directly from PostgreSQL FTP or from http://www.rpmfind.net. When I started with PostgreSQL 7.0 there were no RPMs available then. So I started using the "compile by yourself" way and been happy with it. Until now. I have 7.1.2 running but with same configure options I cannot connigure 7.2.1. It puzzles me, as configure finds ssl.h but not err.h which is in the same directory. > RPMs answer most needs Yes they do. In my situation I'd find it a hassle to first uninstall PostgreSQL (the source installation) and then to install it from RPM and trying to figure out what RH does differently than the default installation (puts things in funny places, I'd assume!). Regards, Peter
Le Lundi 22 Avril 2002 09:23, Peter Peltonen a écrit : > --enable-multibyte=LATIN1 1) Multibyte Latin1 is not a multi-byte character. This is not the way to create a Latin1 database. Creating a Latin1 database is done by CREATE DATABASE foo WITH ENCODING = "Latin1". Anyway, it is now recommanded to use Latin9 (Latin1 + euro support) instead of Latin1. Why don't you simply --enable-multibyte? Then, you will be able to create a Latin1, Latin9 (=Latin1+euro) or Unicode database. PostgreSQL offers automatic recoding between server and client using SET CLIENT_ENCODING = "Latin9". 2) RPMs If you are new to PostgreSQL, why don't you install RPMs? They can be downloaded directly from PostgreSQL FTP or from http://www.rpmfind.net. RPMs answer most needs a) Binary packages installation According to your distributions, binary packages can be downloaded and installed. To install or upgrade, enter "rpm -Uvh package_name1, package_name2 [...] package_nameN". All packages should be installed at once. For Mandrake, my list of installed RPMs is as follows: libecpg3-7.2.1-1mdk.i586.rpm libpgperl-7.2.1-1mdk.i586.rpm libpgsql2-7.2.1-1mdk.i586.rpm libpgsqlodbc0-7.2.1-1mdk.i586.rpm libpgtcl2-7.2.1-1mdk.i586.rpm postgresql-7.2.1-1mdk.i586.rpm postgresql-contrib-7.2.1-1mdk.i586.rpm postgresql-devel-7.2.1-1mdk.i586.rpm postgresql-docs-7.2.1-1mdk.i586.rpm postgresql-jdbc-7.2.1-1mdk.i586.rpm postgresql-python-7.2.1-1mdk.i586.rpm postgresql-server-7.2.1-1mdk.i586.rpm postgresql-tcl-7.2.1-1mdk.i586.rpm postgresql-test-7.2.1-1mdk.i586.rpm postgresql-tk-7.2.1-1mdk.i586.rpm b) Package recompilation If you have a custom architecture (ex: double-processor), it is recommanded to recompile packages. Just download PostgreSQL source package and enter : "rpm --rebuild --target i586 postgresql.src.rpm". Go to /usr/src/RPM/RPMS/i586 to retrieve binary packages. c) Package customization The advantage of RPMs is that you can easily create you own packages with custom compilation options. To do so: - install PostgreSQL source RPM : rpm -Uvh postgresql.src.rpm - modify compilation options in /usr/src/RPM/SPECS/postgresql.spec - enter rpm -ba /usr/src/RPM/SPECS/postgresql.spec This will recreate both source package (*.src.rpm) and binary packages (*.i586.rpm). therefore you will be able to do several installations without bothering. Debian distributions also have their own packages (.deb). So why bother with source code compilation unless you are a hacker and whish to contribute source code to PostgreSQL? Cheers, Jean-Michel
On Mon, 22 Apr 2002, Jean-Michel POURE wrote: > Le Lundi 22 Avril 2002 09:23, Peter Peltonen a écrit : > > 2) RPMs > If you are new to PostgreSQL, why don't you install RPMs? They can be > downloaded directly from PostgreSQL FTP or from http://www.rpmfind.net. > > RPMs answer most needs If you trust them. I'm never convinced my configuration would survive an upgrade. > a) Binary packages installation > According to your distributions, binary packages can be downloaded and > installed. To install or upgrade, enter "rpm -Uvh package_name1, > package_name2 [...] package_nameN". All packages should be installed at once. > > For Mandrake, my list of installed RPMs is as follows: > libecpg3-7.2.1-1mdk.i586.rpm > libpgperl-7.2.1-1mdk.i586.rpm > libpgsql2-7.2.1-1mdk.i586.rpm > libpgsqlodbc0-7.2.1-1mdk.i586.rpm > libpgtcl2-7.2.1-1mdk.i586.rpm > postgresql-7.2.1-1mdk.i586.rpm > postgresql-contrib-7.2.1-1mdk.i586.rpm > postgresql-devel-7.2.1-1mdk.i586.rpm > postgresql-docs-7.2.1-1mdk.i586.rpm > postgresql-jdbc-7.2.1-1mdk.i586.rpm > postgresql-python-7.2.1-1mdk.i586.rpm > postgresql-server-7.2.1-1mdk.i586.rpm > postgresql-tcl-7.2.1-1mdk.i586.rpm > postgresql-test-7.2.1-1mdk.i586.rpm > postgresql-tk-7.2.1-1mdk.i586.rpm > > b) Package recompilation > If you have a custom architecture (ex: double-processor), it is recommanded to > recompile packages. Just download PostgreSQL source package and enter : "rpm > --rebuild --target i586 postgresql.src.rpm". Go to /usr/src/RPM/RPMS/i586 to > retrieve binary packages. > > c) Package customization > The advantage of RPMs is that you can easily create you own packages with > custom compilation options. To do so: > - install PostgreSQL source RPM : rpm -Uvh postgresql.src.rpm > - modify compilation options in /usr/src/RPM/SPECS/postgresql.spec > - enter rpm -ba /usr/src/RPM/SPECS/postgresql.spec > This will recreate both source package (*.src.rpm) and binary packages > (*.i586.rpm). therefore you will be able to do several installations without > bothering. That is a good point. > Debian distributions also have their own packages (.deb). > > So why bother with source code compilation unless you are a hacker and whish > to contribute source code to PostgreSQL? I see you had to fetch and install quite a number of packages to get your postgres system. I fetched postgres....tar.gz, unpacked, configured, made, checked and installed. :) Now if only I sorted out the CVS thing I might keep up to date with the development branch. Background: my first Linux distribution came on 26 floppy disks, 1.0.x kernel (actually might have been the second) and there was none of this fancy packaging stuff that tried to remove control of system configuration from me. -- Nigel J. Andrews Director --- Logictree Systems Limited Computer Consultants
On Mon, 2002-04-22 at 10:54, Jean-Michel POURE wrote: > c) Package customization > The advantage of RPMs is that you can easily create you own packages with > custom compilation options. To do so: > - install PostgreSQL source RPM : rpm -Uvh postgresql.src.rpm > - modify compilation options in /usr/src/RPM/SPECS/postgresql.spec > - enter rpm -ba /usr/src/RPM/SPECS/postgresql.spec > This will recreate both source package (*.src.rpm) and binary packages > (*.i586.rpm). therefore you will be able to do several installations without > bothering. I tried this. It produces the same error as compiling from the real source: --<snip>-- checking for openssl/ssl.h... yes checking for openssl/err.h... no configure: error: header file <openssl/err.h> is required for OpenSSL error: Bad exit status from /var/tmp/rpm-tmp.29209 (%build) --</snip>-- I really don't understand this: [root@cayman SPECS]# ls /usr/include/openssl/ssl.h /usr/include/openssl/ssl.h [root@cayman SPECS]# ls /usr/include/openssl/err.h /usr/include/openssl/err.h Regards, Peter
Peter Peltonen <peter.peltonen@fivetec.com> writes:
> --<snip>--
> checking for openssl/ssl.h... yes
> checking for openssl/err.h... no
> configure: error: header file <openssl/err.h> is required for OpenSSL
> error: Bad exit status from /var/tmp/rpm-tmp.29209 (%build)
> --</snip>--
> I really don't understand this:
Could we see the last few lines of config.log? It might also help to
try hand-compiling the test program for openssl/err.h to see what error
message you get (I don't think config.log will tell you).
An offhand guess is that your version of openssl/err.h depends on some
other header that we're failing to include.
regards, tom lane
On Mon, 2002-04-22 at 18:38, Tom Lane wrote:
> Could we see the last few lines of config.log? It might also help to
> try hand-compiling the test program for openssl/err.h to see what error
> message you get (I don't think config.log will tell you).
Just before you asked I checked the config.log (which I should've done
in the first place) and there it was:
--<snip>--
In file included from /usr/include/errno.h:36,
from /usr/include/openssl/err.h:90,
from configure:5454:
/usr/include/bits/errno.h:25:26: linux/errno.h: No such file or
directory
configure: failed program was:
#line 5453 "configure"
#include "confdefs.h"
#include <openssl/err.h>
--</snip>--
So it wasn't openssl/err.h missing but linux/errno.h. And that was due
to a broken symlink.
A bit misguiding error message from PostgreSQL but my own fault anyway.
Thanks for everyone for help.
Cheers,
Peter