configure: error: header file <openssl/err.h> is required for OpenSSL

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

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