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
Peter Eisentraut <[EMAIL PROTECTED]> 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 necess
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
bet
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 stu
Bruce Momjian <[EMAIL PROTECTED]> 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 th
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. Post
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 basicall
> 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 t
It's best to send the context diffs to it to [EMAIL PROTECTED]
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 li
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 libp
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 b
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-
12 matches
Mail list logo
