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

A libpq library on Mac OS X is made as a loadable library (bundle). Since a
shared library version (dylib) of libpq does not exist, all programs which
use libpq are always linked with a static version of libpq.

Psql made by a current make rule:

$ ls -l /opt/pgsql/7.3/bin/psql psql
-rwxr-xr-x 1 sugita admin 188616 Dec 22 01:25 /opt/pgsql/7.3/bin/psql
$ otool -L /opt/pgsql/7.3/bin/psql
/opt/pgsql/7.3/bin/psql:
/usr/lib/libz.1.1.3.dylib (compatibility version 1.0.0, current version 1.1.3)
/usr/local/lib/libreadline.4.1.dylib (compatibility version 4.0.0, current version 4.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0)
$

Psql made by a handmade shared library:

$ ls -l psql
-rwxr-xr-x 1 sugita wheel 138732 Dec 22 01:34 psql*
$ otool -L psql
psql:
libpq.2.2.dylib (compatibility version 2.0.0, current version 2.2.0)
/usr/lib/libz.1.1.3.dylib (compatibility version 1.0.0, current version 1.1.3)
/usr/local/lib/libreadline.4.1.dylib (compatibility version 4.0.0, current version 4.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0)
$

Kenji Sugita

Kenji Sugita writes:

> A libpq library on Mac OS X is made as a loadable library (bundle). Since a
> shared library version (dylib) of libpq does not exist, all programs which
> use libpq are always linked with a static version of libpq.

Since only Mac OS X has this stupid dichotomy, no one has bothered to do
anything about it yet. Feel free to propose a solution.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Thu, 2003-01-02 at 13:38, Peter Eisentraut wrote:
> Kenji Sugita writes:
>
> > A libpq library on Mac OS X is made as a loadable library (bundle). Since a
> > shared library version (dylib) of libpq does not exist, all programs which
> > use libpq are always linked with a static version of libpq.
>
> Since only Mac OS X has this stupid dichotomy, no one has bothered to do
> anything about it yet. Feel free to propose a solution.

I have a fix for it in the Fink packages. It needs a little reworking,
but basically works.

Give me a few minutes, I'll clean up the patch a bit and pass it on. Is
it OK to post it here, or is there somewhere better to send it?

It's best to send the context diffs to it to pgsql-patches(at)postgresql(dot)org

On Thursday 02 January 2003 11:08, Benjamin Reed wrote:
> On Thu, 2003-01-02 at 13:38, Peter Eisentraut wrote:
> > Kenji Sugita writes:
> > > A libpq library on Mac OS X is made as a loadable library (bundle).
> > > Since a shared library version (dylib) of libpq does not exist, all
> > > programs which use libpq are always linked with a static version of
> > > libpq.
> >
> > Since only Mac OS X has this stupid dichotomy, no one has bothered to do
> > anything about it yet. Feel free to propose a solution.
>
> I have a fix for it in the Fink packages. It needs a little reworking,
> but basically works.
>
> Give me a few minutes, I'll clean up the patch a bit and pass it on. Is
> it OK to post it here, or is there somewhere better to send it?
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com

> I have a fix for it in the Fink packages. It needs a little reworking,
> but basically works.
>
> Give me a few minutes, I'll clean up the patch a bit and pass it on. Is
> it OK to post it here, or is there somewhere better to send it?

I sent out my patch last night. If anyone else wants to try it out or
comment, you can grab it here:

http://ranger.befunk.com/patches/postgresql-7.3.1-1.patch

Please let me know if any of it looks wrong.

This patch has fixes for Darwin, and some PAM configure checks. Is this
to be applied for PostgreSQL 7.4?

---------------------------------------------------------------------------

Benjamin Reed wrote:
> > I have a fix for it in the Fink packages. It needs a little reworking,
> > but basically works.
> >
> > Give me a few minutes, I'll clean up the patch a bit and pass it on. Is
> > it OK to post it here, or is there somewhere better to send it?
>
> I sent out my patch last night. If anyone else wants to try it out or
> comment, you can grab it here:
>
> http://ranger.befunk.com/patches/postgresql-7.3.1-1.patch
>
> Please let me know if any of it looks wrong.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wednesday, January 8, 2003, at 08:02 PM, Bruce Momjian wrote:

> This patch has fixes for Darwin, and some PAM configure checks. Is
> this
> to be applied for PostgreSQL 7.4?

It was made against 7.3.1, but it's up to you guys as to whether it's
too invasive to change in the stable releases. PostgreSQL's building
all static right now so it's not really an upgrade issue in changing
things around -- I just haven't tested on any other platforms, so I
haven't confirmed if it messes anything else up.

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> This patch has fixes for Darwin, and some PAM configure checks. Is this
> to be applied for PostgreSQL 7.4?

I was unhappy that the patch seemed to be tweaking stuff that wasn't
directly related to the claimed purpose.

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.

regards, tom lane

On Wednesday, January 8, 2003, at 10:56 PM, Tom Lane wrote:

> I was unhappy that the patch seemed to be tweaking stuff that wasn't
> directly related to the claimed purpose.
>
> 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.

That's fine, I was actually caught slightly off-guard. I had patches
put together but wasn't prepared to give them to the world yet, but
when it came up on the list, I put it out just so that no one ended up
duplicating effort. =)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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.

That bothered me too. Got a suggestion for a better name?

regards, tom lane

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(at)gmx(dot)net

I said:
>> I will test and apply the parts that are related to OS X shared library
>> behavior.

For the moment I am forced to reject this patch entirely, because it
breaks the regression tests.

The trouble is that src/test/regress/GNUmakefile doesn't use
Makefile.shlib, but relies on the contents of the port makefile
to build regress.so. The patch changes Makefile.darwin to define
DLSUFFIX as .dylib, but the provided rule for making a dylib is
inappropriate for the regression shlib.

I am inclined to think that the right answer is to give up the shortcut
of not including Makefile.shlib in regress/GNUmakefile ... in which case
we could probably remove the stub .so rules from the port makefiles
altogether. But I don't have time at the moment to investigate this.

regards, tom lane