peter_e@gmx.net (Peter Eisentraut) wrote in message
news:<Pine.LNX.4.44.0311242011220.21306-100000@peter.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
