Re: Libpq is not a shared library on Mac OS X

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Libpq is not a shared library on Mac OS X
Дата
Msg-id Pine.LNX.4.44.0301092057540.29178-100000@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Libpq is not a shared library on Mac OS X  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Libpq is not a shared library on Mac OS X  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Libpq is not a shared library on Mac OS X  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Tom Lane writes:

> I will test and apply the parts that are related to OS X shared library
> behavior.  If Benjamin wants to advocate the other stuff (like pam.h
> search path) that should be handled as separate patches.

One thing I like about the patch is that it introduces a differentiation
between run-time loadable modules and build-time linkable libraries, which
is something I've wanted to do for a while.  Even on platforms where this
isn't technically necessary we could choose better file names, such as
plpgsql.so instead of libplpgsql.so.0.0.  I'd prefer if a more general
term than "bundle" is used.

However, the trick is that some libraries may be used both ways.  For
example, libpgtcl is build-time linked by pgtclsh but run-time loaded by
PgAccess.  (PgAccess uses the shared-library extension provided by the Tcl
configuration interface, which might be equally confused about this issue.
It's further complicated because you can actually run-time load the
build-time linkable file type if you try hard enough.  So be sure to check
that whatever you do works with PgAccess.)

--
Peter Eisentraut   peter_e@gmx.net

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Hubert depesz Lubaczewski
Дата:
Сообщение: Re: dropping user doesn't erase his rights.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Libpq is not a shared library on Mac OS X