Re: $libdir and 8.0
От | Paul Ramsey |
---|---|
Тема | Re: $libdir and 8.0 |
Дата | |
Msg-id | 412433D4.9080902@refractions.net обсуждение исходный текст |
Ответ на | Re: $libdir and 8.0 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: $libdir and 8.0
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: