Re: Libpq is not a shared library on Mac OS X - Mailing list pgsql-bugs

From Peter Eisentraut
Subject Re: Libpq is not a shared library on Mac OS X
Date
Msg-id Pine.LNX.4.44.0301092057540.29178-100000@localhost.localdomain
Whole thread Raw
In response to Re: Libpq is not a shared library on Mac OS X  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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>)
List 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 by date:

Previous
From: Hubert depesz Lubaczewski
Date:
Subject: Re: dropping user doesn't erase his rights.
Next
From: Tom Lane
Date:
Subject: Re: Libpq is not a shared library on Mac OS X