initdb has trouble finding the right ascii_and_mic.so
Hello pgsql-general,
I'm having trouble initializing the database cluster. Here's how it does:
netra ~ # (cd /var/opt/csw/postgresql/8.4/pgdata; truss -f -o
/var/tmp/initdb.truss su postgres -c
"/opt/csw/lib/postgresql/8.4/bin/sparcv9/initdb -D
/var/opt/csw/postgresql/8.4/pgdata -E utf-8")
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale en_US.UTF-8.
The default text search configuration will be set to "english".
fixing permissions on existing directory
/var/opt/csw/postgresql/8.4/pgdata ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating configuration files ... ok
creating template1 database in /var/opt/csw/postgresql/8.4/pgdata/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... FATAL: could not load library
"/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so": ld.so.1: postgres:
fatal: /opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so: wrong ELF
class: ELFCLASS32
STATEMENT: CREATE OR REPLACE FUNCTION ascii_to_mic (INTEGER, INTEGER,
CSTRING, INTERNAL, INTEGER) RETURNS VOID AS '$libdir/ascii_and_mic',
'ascii_to_mic' LANGUAGE C STRICT;
child process exited with exit code 1
initdb: removing contents of data directory "/var/opt/csw/postgresql/8.4/pgdata"
-------------------
There are 2 sets of libraries installed.
/opt/csw/lib/postgresql/8.4/lib contains 32-bit libraries.
/opt/csw/lib/postgresql/8.4/lib/64 contains the 64-bit set.
Here's what initdb does:
7584: stat("/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic",
0xFFFFFFFF7FFFE610) Err#2 ENOENT
7584: stat("/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so",
0xFFFFFFFF7FFFE610) = 0
7584: stat("/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so",
0xFFFFFFFF7FFFE6C0) = 0
7584: stat("/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so",
0xFFFFFFFF7FFFDD20) = 0
7584: resolvepath("/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so",
"/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so", 1023) = 48
7584: open("/opt/csw/lib/postgresql/8.4/lib/ascii_and_mic.so", O_RDONLY) = 37
If I understand correctly, the problem is that
/opt/csw/lib/postgresql/8.4/bin/initdb looks for the libraries in the
wrong place: /opt/csw/lib/postgresql/8.4/lib instead of
/opt/csw/lib/postgresql/8.4/lib/64. How can I tell it to look there?
Maciej
"Maciej (Matchek) Blizinski" <blizinski@google.com> writes:
There are 2 sets of libraries installed.
/opt/csw/lib/postgresql/8.4/lib contains 32-bit libraries.
/opt/csw/lib/postgresql/8.4/lib/64 contains the 64-bit set.
You can't just make up some random layout for the libraries.
Even if this could work, I don't see a lot of point to it.
Why don't you set up two independent installation trees if
you want to have both 32- and 64-bit postgres installed?
regards, tom lane
On Sun, Jan 10, 2010 at 4:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Maciej (Matchek) Blizinski" <blizinski@google.com> writes:
There are 2 sets of libraries installed.
/opt/csw/lib/postgresql/8.4/lib contains 32-bit libraries.
/opt/csw/lib/postgresql/8.4/lib/64 contains the 64-bit set.You can't just make up some random layout for the libraries.
The layout is not exactly random. On Solaris:
maciej@netra ~ $ ls -ld /usr/lib/32
lrwxrwxrwx 1 root root 1 Feb 14 2009 /usr/lib/32 -> .
maciej@netra ~ $ ls -ld /usr/lib/64
lrwxrwxrwx 1 root root 7 Feb 14 2009 /usr/lib/64 -> sparcv9
And, by analogy:
maciej@netra ~ $ ls -ld /opt/csw/lib/32
lrwxrwxrwx 1 root root 1 Sep 25 08:48 /opt/csw/lib/32 -> .
maciej@netra ~ $ ls -ld /opt/csw/lib/64
lrwxrwxrwx 1 root root 7 Sep 25 08:48 /opt/csw/lib/64 -> sparcv9
The whole operating system is laid out this way. The issue of finding
the right set of libraries is solved in the following way:
maciej@netra ~ $ /usr/ccs/bin/dump -Lv /opt/csw/bin/sparcv8/gpg |
gegrep 'R(UN|)PATH'
[13]: RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:/opt/csw/lib
/opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:/opt/csw/lib
[14]: RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:/opt/csw/lib maciej@netra ~ $ /usr/ccs/bin/dump -Lv /opt/csw/bin/sparcv9/gpg | gegrep 'R(UN|)PATH'
/opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib:/opt/csw/lib
maciej@netra ~ $ /usr/ccs/bin/dump -Lv /opt/csw/bin/sparcv9/gpg |
gegrep 'R(UN|)PATH'
[11]: RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib/64
[12]: RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib/64
$ISALIST expands to:
sparcv9+vis sparcv9 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld
sparcv7 sparc
The binary checks each element of this list, substituting the $ISALIST
token for the path. After the expansion, /opt/csw/lib/$ISALIST
becomes /opt/csw/lib/sparcv9+vis, /opt/csw/lib/sparcv9,
/opt/csw/lib/sparcv8plus+vis, etc.
In the case of the initdb binary:
maciej@netra ~ $ /usr/ccs/bin/dump -Lv
/opt/csw/lib/postgresql/8.4/bin/sparcv8/initdb | gegrep 'R(UN|)PATH'
[17]: RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib/64:/opt/csw/lib/postgresql/8.4/lib
/opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib:/opt/csw/lib:/opt/csw/lib/postgresql/8.4/lib
[18]: RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib/64:/opt/csw/lib/postgresql/8.4/lib
/opt/csw/lib/$ISALIST:/opt/csw/lib:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib:/opt/csw/lib:/opt/csw/lib/postgresql/8.4/lib
maciej@netra ~ $ /usr/ccs/bin/dump -Lv
/opt/csw/lib/postgresql/8.4/bin/sparcv9/initdb | gegrep 'R(UN|)PATH'
[17]: RUNPATH /opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib/64:/opt/csw/lib/postgresql/8.4/lib
/opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib/64:/opt/csw/lib/postgresql/8.4/lib
[18]: RPATH /opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib/64:/opt/csw/lib/postgresql/8.4/lib
/opt/csw/lib/$ISALIST:/opt/csw/lib/64:/opt/csw/lib/postgresql/8.4/lib/$ISALIST:/opt/csw/lib/postgresql/8.4/lib/64:/opt/csw/lib/postgresql/8.4/lib
The search path for the 64-bit binary is:
/opt/csw/lib/$ISALIST
/opt/csw/lib/64
/opt/csw/lib/postgresql/8.4/lib/$ISALIST
/opt/csw/lib/postgresql/8.4/lib/64
/opt/csw/lib/postgresql/8.4/lib
All the binaries have this RPATH set, so they have enough information
to find the right libraries.
Even if this could work, I don't see a lot of point to it.
Why don't you set up two independent installation trees if
you want to have both 32- and 64-bit postgres installed?
That is an option, but I wanted to avoid separate installation trees
in the first place. I'm working on replicating the Debian layout, to
support installing multiple PostgreSQL versions at the same time.
Currently, OpenCSW package[1]http://www.opencsw.org/packages/postgresql install PostgreSQL in
/opt/csw/postgresql and there's no room for another version and/or for
data migration. There are also issues with things like the PATH
setting, so the PostgreSQL package doesn't work out of the box. I
want to fix that.
My options seem to be:
- find a way to make initdb use the information from RPATH
- ship 32-bit binaries only
Maciej