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

Libpq is not a shared library on Mac OS X

From
Kenji Sugita
Date:
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

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

From
Peter Eisentraut
Date:
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@gmx.net

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

From
Benjamin Reed
Date:
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?

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

From
Darcy Buskermolen
Date:
It's best to send the context diffs to it to pgsql-patches@postgresql.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@postgresql.org)

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

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

From
Benjamin Reed
Date:
> 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.

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

From
Bruce Momjian
Date:
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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

From
Benjamin Reed
Date:
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.

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

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.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

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

From
Benjamin Reed
Date:
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.  =)

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

From
Peter Eisentraut
Date:
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

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

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.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

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

From
Tom Lane
Date:
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