$libdir and 8.0
Short bug report:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.
Paul
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.
I'm not sure but if you add /opt/foo/lib/postgresql to /etc/ld.so.conf and
run ldconfig, it might work.
Regards,
--
Devrim GUNDUZ
devrim~gunduz.org devrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
Devrim GUNDUZ wrote:
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.I'm not sure but if you add /opt/foo/lib/postgresql to /etc/ld.so.conf and
run ldconfig, it might work.
I checked in the code and $libdir should expand to $(pkglibdir) as
determined by configure. What value to you show for that in
your Makefile.global?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073The expansions in the build scripts all seem correct, and in fact, all
the libraries are installed in the right place, both the system stuff
(plpgsql.so) and the contrib stuff (libpostgis.so) ends up in
/opt/foo/lib/postgresql. It is the actual binaries that seem to not know
where $libdir is supposed to be.
prefix := /home/pramsey/pgtest/8.0
exec_prefix := ${prefix}
libdir := ${exec_prefix}/lib
pkglibdir = $(libdir)
ifeq "$(findstring pgsql, $(pkglibdir))" ""
ifeq "$(findstring postgres, $(pkglibdir))" ""
override pkglibdir := $(pkglibdir)/postgresql
endif
endif
Bruce Momjian wrote:
Show quoted text
Devrim GUNDUZ wrote:
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.I'm not sure but if you add /opt/foo/lib/postgresql to /etc/ld.so.conf and
run ldconfig, it might work.I checked in the code and $libdir should expand to $(pkglibdir) as
determined by configure. What value to you show for that in
your Makefile.global?
Check this out!
[pramsey@localhost bin]$ ./pg_config --pkglibdir
/home/pramsey/pgtest/8.0/bin/lib/postgresql
^^^
And yet:
./port/pg_config_paths.h:#define PKGLIBDIR
"/home/pramsey/pgtest/8.0/lib/postgresql"
Could the problem be here? (port/path.c):
/*
* get_pkglib_path
*/
void
get_pkglib_path(const char *my_exec_path, char *ret_path)
{
const char *p;
if ((p = relative_path(PGBINDIR, PKGLIBDIR)))
make_relative(my_exec_path, p, ret_path);
else
StrNCpy(ret_path, PKGLIBDIR, MAXPGPATH);
canonicalize_path(ret_path);
}
Bruce Momjian wrote:
Show quoted text
Devrim GUNDUZ wrote:
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.I'm not sure but if you add /opt/foo/lib/postgresql to /etc/ld.so.conf and
run ldconfig, it might work.I checked in the code and $libdir should expand to $(pkglibdir) as
determined by configure. What value to you show for that in
your Makefile.global?
Ah, what is your $bindir? Is it /home/pramsey/pgtest/8.0/bin/postgresql?
---------------------------------------------------------------------------
Paul Ramsey wrote:
Check this out!
[pramsey@localhost bin]$ ./pg_config --pkglibdir
/home/pramsey/pgtest/8.0/bin/lib/postgresql
^^^And yet:
./port/pg_config_paths.h:#define PKGLIBDIR
"/home/pramsey/pgtest/8.0/lib/postgresql"Could the problem be here? (port/path.c):
/*
* get_pkglib_path
*/
void
get_pkglib_path(const char *my_exec_path, char *ret_path)
{
const char *p;if ((p = relative_path(PGBINDIR, PKGLIBDIR)))
make_relative(my_exec_path, p, ret_path);
else
StrNCpy(ret_path, PKGLIBDIR, MAXPGPATH);
canonicalize_path(ret_path);
}Bruce Momjian wrote:
Devrim GUNDUZ wrote:
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.I'm not sure but if you add /opt/foo/lib/postgresql to /etc/ld.so.conf and
run ldconfig, it might work.I checked in the code and $libdir should expand to $(pkglibdir) as
determined by configure. What value to you show for that in
your Makefile.global?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Paul Ramsey <pramsey@refractions.net> writes:
... It is the actual binaries that seem to not know
where $libdir is supposed to be.
Where do they think it is?
A useful way to check would be to strace the backend while you're
executing "createlang" or another command that tries to load a
dynamic library. The file names that it tries to stat() would be
good evidence.
Also, how are you starting the postmaster? I believe that current
sources will try to locate $libdir via a relative path from where
the postmaster executable is. We've fixed some bugs in that area
recently, but maybe there are more.
regards, tom lane
I am afraid it gets crazier...
I put /home/pramsey/pgtest/8.0/bin on my $PATH
Now:
[pramsey@localhost 8.0]$ pg_config --pkglibdir
/home/pramsey/pgtest/8.0/lib/postgresql
Hm, correct.
[pramsey@localhost 8.0]$ ./bin/pg_config --pkglibdir
/home/pramsey/pgtest/8.0/./lib/postgresql
Also correct, but getting strangely relative.
[pramsey@localhost 8.0]$ cd bin
[pramsey@localhost bin]$ ./pg_config --pkglibdir
/home/pramsey/pgtest/8.0/bin/lib/postgresql
Now incorrect. The answer depends on where I am asking from.
[pramsey@localhost bin]$ ./pg_config --bindir
/home/pramsey/pgtest/8.0/bin/.
Using the direct request. Using the $PATH assisted request:
[pramsey@localhost bin]$ pg_config --bindir
/home/pramsey/pgtest/8.0/bin
Entirely correct.
Problem solved? No...
[pramsey@localhost bin]$ createlang plpgsql test
ERROR: could not access file "$libdir/plpgsql": No such file or directory
createlang: language installation failed: ERROR: could not access file
"$libdir/plpgsql": No such file or directory
If I copy plpgsql.so into /home/pramsey/pgtest/8.0/lib then things work.
Bruce Momjian wrote:
Show quoted text
Ah, what is your $bindir? Is it /home/pramsey/pgtest/8.0/bin/postgresql?
---------------------------------------------------------------------------
Paul Ramsey wrote:
Check this out!
[pramsey@localhost bin]$ ./pg_config --pkglibdir
/home/pramsey/pgtest/8.0/bin/lib/postgresql
^^^And yet:
./port/pg_config_paths.h:#define PKGLIBDIR
"/home/pramsey/pgtest/8.0/lib/postgresql"Could the problem be here? (port/path.c):
/*
* get_pkglib_path
*/
void
get_pkglib_path(const char *my_exec_path, char *ret_path)
{
const char *p;if ((p = relative_path(PGBINDIR, PKGLIBDIR)))
make_relative(my_exec_path, p, ret_path);
else
StrNCpy(ret_path, PKGLIBDIR, MAXPGPATH);
canonicalize_path(ret_path);
}Bruce Momjian wrote:
Devrim GUNDUZ wrote:
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched for
$libdir (perhaps it is referencing the $libdir macro instead of the
$pkglibdir macro?). So tools like 'createlang' fail, and loading .sql
files that reference things like $libdir/libfoo.so also fail.I'm not sure but if you add /opt/foo/lib/postgresql to /etc/ld.so.conf and
run ldconfig, it might work.I checked in the code and $libdir should expand to $(pkglibdir) as
determined by configure. What value to you show for that in
your Makefile.global?
Sounds like we are getting close. From strace:
stat64("/home/pramsey/pgtest/8.0/bin/lib/postgresql/plpgsql",
0xbfffe480) = -1 ENOENT (No such file or directory)
stat64("/home/pramsey/pgtest/8.0/bin/lib/postgresql/plpgsql.so",
0xbfffe480) = -1 ENOENT (No such file or directory)
stat64("$libdir/plpgsql", 0xbfffe540) = -1 ENOENT (No such file or
directory)
I started the database from "/home/pramsey/pgtest/8.0/bin" using
"./pg_ctl start -D /home/pramsey/pgtest/8.0/data"
Judging from the behavior I have posted to the list of "pg_config
--pkglibdir", if I started it from any *other* location at all then
things would have worked.
Paul
Tom Lane wrote:
Show quoted text
Paul Ramsey <pramsey@refractions.net> writes:
... It is the actual binaries that seem to not know
where $libdir is supposed to be.Where do they think it is?
A useful way to check would be to strace the backend while you're
executing "createlang" or another command that tries to load a
dynamic library. The file names that it tries to stat() would be
good evidence.Also, how are you starting the postmaster? I believe that current
sources will try to locate $libdir via a relative path from where
the postmaster executable is. We've fixed some bugs in that area
recently, but maybe there are more.regards, tom lane
Things definately do not like to be run from within "bin". I added
/home/pramsey/pgtest/8.0/bin to my PATH and then ran everything without
a direct path reference:
[pramsey@localhost 8.0]$ pg_ctl start -D /home/pramsey/pgtest/8.0/data
postmaster starting
LOG: database system was shut down at 2004-08-18 22:00:32 PDT
LOG: checkpoint record is at 0/B2797C
LOG: redo record is at 0/B2797C; undo record is at 0/0; shutdown TRUE
LOG: next transaction ID: 628; next OID: 17263
LOG: database system is ready
[pramsey@localhost 8.0]$ createdb test
CREATE DATABASE
[pramsey@localhost 8.0]$ createlang plpgsql test
[pramsey@localhost 8.0]$
Magically, everything now works :)
Tom Lane wrote:
Show quoted text
Paul Ramsey <pramsey@refractions.net> writes:
... It is the actual binaries that seem to not know
where $libdir is supposed to be.Where do they think it is?
A useful way to check would be to strace the backend while you're
executing "createlang" or another command that tries to load a
dynamic library. The file names that it tries to stat() would be
good evidence.Also, how are you starting the postmaster? I believe that current
sources will try to locate $libdir via a relative path from where
the postmaster executable is. We've fixed some bugs in that area
recently, but maybe there are more.regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Paul Ramsey <pramsey@refractions.net> writes:
I started the database from "/home/pramsey/pgtest/8.0/bin" using
"./pg_ctl start -D /home/pramsey/pgtest/8.0/data"
Ah-hah ... and this is 8.0beta1, right, not anything later?
I fixed some problems associated with "." and ".." in the executable's
path last week. I think if you pull the current nightly snapshot or
CVS you will find the problem gone.
regards, tom lane
Thanks Tom,
Yes, this is beta1, not the CVS tip, so all is golden.
Paul
Tom Lane wrote:
Show quoted text
Paul Ramsey <pramsey@refractions.net> writes:
I started the database from "/home/pramsey/pgtest/8.0/bin" using
"./pg_ctl start -D /home/pramsey/pgtest/8.0/data"Ah-hah ... and this is 8.0beta1, right, not anything later?
I fixed some problems associated with "." and ".." in the executable's
path last week. I think if you pull the current nightly snapshot or
CVS you will find the problem gone.regards, tom lane