On Tue, Jul 05, 2005 at 07:20:48PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Ok Tom, you win. It is indeed possible to make it work, and the
resulting makefile is even cleaner than before.
Following patch thus autoconfigures pgcrypto. It drops the
possibility to use libc's
Marko Kreen marko@l-t.ee writes:
! PG_CPPFLAGS := $(CF_CFLAGS) -I$(srcdir) $(PG_CPPFLAGS)
...
! PG_CPPFLAGS = $(CF_CFLAGS) -I$(srcdir)
Ah, right. Actually we don't need -I$(srcdir) either, since pgxs.mk
adds that automatically.
regards, tom lane
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.
I haven't dug into the pgcrypto code yet -- is it doing anything
that might be platform-specific? Or is this
Michael Fuhr [EMAIL PROTECTED] writes:
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.
I haven't dug into the pgcrypto code yet -- is it doing anything
On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.
I haven't dug into the pgcrypto code yet
On Tue, Jul 05, 2005 at 07:21:17PM +0300, Marko Kreen wrote:
It is a bug in pgcrypto. I can only excuse it with my strong antipathy
towards 3des.
Could you test it with newer OpenSSL?
Looks good. After applying the patch, all pgcrypto regression tests
pass on my box running Solaris
Michael Fuhr [EMAIL PROTECTED] writes:
On Tue, Jul 05, 2005 at 07:21:17PM +0300, Marko Kreen wrote:
It is a bug in pgcrypto. I can only excuse it with my strong antipathy
towards 3des.
Looks good. After applying the patch, all pgcrypto regression tests
pass on my box running Solaris
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older versions of OpenSSL; I'll do so when I get a chance.
It is a
Tom Lane wrote:
Now that I look, the reason the buildfarm failed to find this is of
course that the pgcrypto Makefile is configured to never build or test
this code. Would it be reasonable to fix the makefile to follow the
toplevel --with-openssl choice?
Yes, please! good catch!
On Tue, Jul 05, 2005 at 02:18:00PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 08:40:08AM -0600, Michael Fuhr wrote:
On my Solaris 9/sparc box with OpenSSL 0.9.8-beta6, the pgcrypto
regression tests fail the 3des test. I haven't checked against
older
Marko Kreen marko@l-t.ee writes:
I see 2 variants:
1) put @with_openssl@ and @with_zlib@ variables into
contrib/pgcrypto/Makefile.in and let configure process it.
2) put them in some other makefile fragment under src/
and let pgcrypto include it.
First I did the simple thing and put
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
Hm ... libpq manages to build code that requires openssl without
needing a generated Makefile, so why do we need it here?
Now, looking more into it, it indeed does work.
But it breaks pgcrypto build
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
I see 2 variants:
1) put @with_openssl@ and @with_zlib@ variables into
contrib/pgcrypto/Makefile.in and let configure process it.
2) put them in some other makefile fragment under src/
and
On Tue, Jul 05, 2005 at 03:36:06PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 02:55:07PM -0400, Tom Lane wrote:
Hm ... libpq manages to build code that requires openssl without
needing a generated Makefile, so why do we need it here?
Now, looking
Marko Kreen marko@l-t.ee writes:
Oh, ofcourse I would not need to break it, if the interesting
settings can be put into eg. src/Makefile.config (.in), and
I include that one.
You mean Makefile.global.in, no? That seems fine to me.
But that case would break if top_srcdir is not ../..
No it
On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Oh, ofcourse I would not need to break it, if the interesting
settings can be put into eg. src/Makefile.config (.in), and
I include that one.
You mean Makefile.global.in, no? That seems fine to
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
You mean Makefile.global.in, no? That seems fine to me.
No, thats the point - the PGXS include also includes
Makefile.global, and including it twice does not work.
So? pgxs.mk includes
On Tue, Jul 05, 2005 at 04:16:04PM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 05, 2005 at 03:58:43PM -0400, Tom Lane wrote:
You mean Makefile.global.in, no? That seems fine to me.
No, thats the point - the PGXS include also includes
Makefile.global, and
Marko Kreen marko@l-t.ee writes:
Ok Tom, you win. It is indeed possible to make it work, and the
resulting makefile is even cleaner than before.
Following patch thus autoconfigures pgcrypto. It drops the
possibility to use libc's crypt, which was pointless.
Applied with a little extra
19 matches
Mail list logo
