Re: Can't initdb, libdir points to static location

I use PostgreSQL as a default database in our solution and with the
7.2 version I was able to tar up the area pointed to by the --prefix
build argument and untar to an arbitrary path as part of my product
installation and I could initdb the database no problem and get a
running database setup completely.

With the 7.4 released version I get this failure while running initdb:

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

This is due to the fact that the libdir is pointing to the lib under
the prefix area I specified when I built the postgresql distribution,
but it no longer exists.

I tried modifying initdb to add the -c dynamic_library_path=<mypath>
but that didn't help. It appears that libdir is basically hardcoded to
be PKGLIBDIR from the build, which won't work in this case.

Setting dynamic_library_path=<mypath> in the postgresql.conf would
work I think, except that initdb doesn't use that at creation time.
The datadir has to be empty an initdb time.

Is there an environment variable that can override this like
LD_LIBRARY_PATH ?
I'm looking for any ideas. Thanks.

Tim Farrell

Tim Farrell writes:

> I use PostgreSQL as a default database in our solution and with the
> 7.2 version I was able to tar up the area pointed to by the --prefix
> build argument and untar to an arbitrary path as part of my product
> installation and I could initdb the database no problem and get a
> running database setup completely.

OK, but it was never intended that this would work. In fact, it was
specifically documented as not working well. Maybe you want to do 'make
install DESTDIR=...' instead, to create a "fake root" installation that
you can tar up.

> Is there an environment variable that can override this like
> LD_LIBRARY_PATH ?

There isn't one right now, but the environment variable might not be a bad
idea.

--
Peter Eisentraut peter_e(at)gmx(dot)net

peter_e(at)gmx(dot)net (Peter Eisentraut) wrote in message news:<Pine(dot)LNX(dot)4(dot)44(dot)0311242011220(dot)21306-100000(at)peter(dot)localdomain>...
> Tim Farrell writes:
>
> > I use PostgreSQL as a default database in our solution and with the
> > 7.2 version I was able to tar up the area pointed to by the --prefix
> > build argument and untar to an arbitrary path as part of my product
> > installation and I could initdb the database no problem and get a
> > running database setup completely.
>
> OK, but it was never intended that this would work. In fact, it was
> specifically documented as not working well. Maybe you want to do 'make
> install DESTDIR=...' instead, to create a "fake root" installation that
> you can tar up.

Setting DESTDIR doesn't fix the issue because the macro referenced in
the conversion_create.sql script is defined at compile time to take
whatever value
PKGPREFIX resolves to. This means that no matter what path I use to
compile the distribution with, the $libdir will not resolve correctly.
If I tar up the distribution and untar it into an arbitrary directory
the $libdir will not resolve to find the correct shared libraries.

>
> > Is there an environment variable that can override this like
> > LD_LIBRARY_PATH ?
>
> There isn't one right now, but the environment variable might not be a bad
> idea.

To work around this I changed dfmgr.c to look for an alternate value
for $libdir if the compile time value of PKGPREFIX doesn't exist in
the environment variable PGDATA. Its a hack but it works for me right
now.

Seems to me that removing the path from the shared libraries
referenced in the conversion_create.sql script and letting them be
found with LD_LIBRARY_PATH and dlopen would be a better way to handle
this. There must be some history as to why the $libdir macro is used
in this case that is preventing a solution like this ?

Thanks for the new 7.4 version of postgres, we were using 7.2.1
previously. Keep up the good work.

Tim