Обсуждение: $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, Pennsylvania19073
The 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:
> 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:
> 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,
Pennsylvania19073
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:
> 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:
> 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: > 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: > 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