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

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