Thread: 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@gmx.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@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
> 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@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
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@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
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. =)
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
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
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