Thread: conversion_create.sql (Related to BUG#1072)

I am having a problem with doing an initdb in 7.4.2.

How I compiled it:
./configure
make
make install

So the binaries/libraries were intalled in /usr/local/pgsql.

I then moved /usr/local/pgsql to /usr/local/pgsql.7.4.2

Following is how I tried initdb and it fails, not being able to resolve
$libdir
in conversion_create.sql.

bash$
bash$ initdb -D /usr/local/pgsql.7.4.2/data -L /usr/local/pgsql.7.4.2/share/
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.

fixing permissions on existing directory /usr/local/pgsql.7.4.2/data... ok
creating directory /usr/local/pgsql.7.4.2/data/base... ok
creating directory /usr/local/pgsql.7.4.2/data/global... ok
creating directory /usr/local/pgsql.7.4.2/data/pg_xlog... ok
creating directory /usr/local/pgsql.7.4.2/data/pg_clog... ok
selecting default max_connections... 100
selecting default shared_buffers... 1000
creating configuration files... ok
creating template1 database in /usr/local/pgsql.7.4.2/data/base/1... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ERROR:  could not access file
"$libdir/ascii_and_mic": No such file or directory

initdb: failed
bash$


If I edit conversion_create.sql to change all references of $libdir to
"/usr/local/pgsql.7.4.2"
then it works well.

Is there any workaround for this where I don't have to change
conversion_date.sql.

Thanks in advance for all help,
guna.

Gunasekaran Balakrishnan <guna@motorola.com> writes:
> creating conversions... ERROR:  could not access file
> "$libdir/ascii_and_mic": No such file or directory

What does "pg_config --pkglibdir" report?  Is ascii_and_mic.so actually
present in that directory?  If so, I would guess that the "no such file"
failure actually means that the dynamic loader couldn't locate some
other shared library that ascii_and_mic.so depends on.  Use ldd or local
equivalent to inspect ascii_and_mic.so's library dependencies.  You
might need to fool with ldconfig settings or some such.

On the other hand, if "pg_config --pkglibdir" doesn't point to where
ascii_and_mic.so is installed, then you messed up something in the
Postgres configure or build process.  I think I've heard of people
getting into this sort of problem by reconfiguring partway through the
build.  The best bet if you want to reconfigure is to "gmake distclean"
and start the build over.

> If I edit conversion_create.sql to change all references of $libdir to
> "/usr/local/pgsql.7.4.2"
> then it works well.

This is certainly not the correct fix.

            regards, tom lane

Tom Lane wrote:

Gunasekaran Balakrishnan <guna@motorola.com> writes: 

creating conversions... ERROR:  could not access file 
"$libdir/ascii_and_mic": No such file or directory   

What does "pg_config --pkglibdir" report?  Is ascii_and_mic.so actually
present in that directory?  If so, I would guess that the "no such file"
failure actually means that the dynamic loader couldn't locate some
other shared library that ascii_and_mic.so depends on.  Use ldd or local
equivalent to inspect ascii_and_mic.so's library dependencies.  You
might need to fool with ldconfig settings or some such. 

"pg_config --pkglibdir" shows me "/usr/local/pgsql/lib".

Since I did not specify --prefix when I did a configure, I assume it took
the default as /usr/local/pgsql/.

So, it it that the this path is fixed and that I have to always have pgsql installed
only in this path ?
So, if I need the install directory to be /usr/local/pgsql.7.4.2 instead, do I need
to recompile completely ?

Actually, I wanted to compile postgres 7.4.2 and distribute the binaries/libraries
it to my team. So, is it mandatory that they take the also place the binaries/libraries
in the same location -- "/usr/local/pgsql" ?
So, is this path configurable at runtime ?
This was not the case with 7.2.2 where I could place the binaries/libraries in a
different place than where it was installed during compilation.

Thanks a lot,
guna.

Gunasekaran Balakrishnan <guna@motorola.com> writes:
> So, is this path configurable at runtime ?

No.

> This was not the case with 7.2.2 where I could place the
> binaries/libraries in a different place than where it was installed
> during compilation.

We have never supported moving stuff around from where you told
configure to put it.  You might not have happened to hit one of the
problem cases when working with 7.2, but they were certainly there.

            regards, tom lane