On Fri, Jul 15, 2005 at 08:06:15PM -0500, Kris Jurka wrote:
On Fri, 15 Jul 2005, Marko Kreen wrote:
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just
building
with the Sun
Marko Kreen marko@l-t.ee writes:
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just building
with the Sun compiler and it works fine. It links all of libz.a into
libpgcrypto.so while gcc refuses to.
I googled a
On Sat, 16 Jul 2005, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
I googled a bit and found two suggestions:
1. http://curl.haxx.se/mail/lib-2002-01/0092.html
(Use -mimpure-text on linking line)
This sure seems like a crude band-aid rather than an actual solution.
The bug as
Kris Jurka [EMAIL PROTECTED] writes:
On Sat, 16 Jul 2005, Tom Lane wrote:
This sure seems like a crude band-aid rather than an actual solution.
The bug as I see it is that gcc is choosing to link libz.a rather than
libz.so --- why is that happening?
The link line says -L/usr/local/lib -lz
On Sat, 16 Jul 2005, Tom Lane wrote:
Kris Jurka [EMAIL PROTECTED] writes:
The link line says -L/usr/local/lib -lz and libz.a is in /usr/local/lib
while libz.so is in /usr/lib.
Well, that is a flat-out configuration error on the local sysadmin's
part. I can't think of any good
Kris Jurka [EMAIL PROTECTED] writes:
consider what would happen if the shared library didn't exist at all and
only a static version were available. Until this recent batch of pgcrypto
changes everything built fine.
Well, the right answer to that really is that pgcrypto ought not try to
link
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just building
with the Sun compiler and it works fine. It links all of libz.a into
libpgcrypto.so while gcc refuses to.
I googled a bit and
On Fri, 15 Jul 2005, Marko Kreen wrote:
[buildfarm machine dragonfly]
On Tue, Jul 12, 2005 at 01:06:46PM -0500, Kris Jurka wrote:
Well the buildfarm machine kudu is actually the same machine just building
with the Sun compiler and it works fine. It links all of libz.a into
On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote:
Marko Kreen wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04
Linking problem with zlib on Solaris 9/x86. I am clueless about
this. I can anyone look into it?
It appears to be
On Tue, 12 Jul 2005, Marko Kreen wrote:
On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote:
Marko Kreen wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04
Linking problem with zlib on Solaris 9/x86. I am clueless about
this. I can
Seems like down mail server ate first mail.
Here it is again.
On Tue, Jul 12, 2005 at 12:51:44PM +0300, Marko Kreen wrote:
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x and internal AES. (I tested it with
0.9.7 only, so I didn't notice...)
- Also I noticed that the wrapper macros for CBC mode
do
Marko Kreen marko@l-t.ee writes:
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x and internal AES. (I tested it with
0.9.7 only, so I didn't notice...)
- Also I noticed
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=potorooodt=2005-07-10%2022:30:03
New sha2 code on Solaris 2.8 / SPARC. Seems like it has
problems memcpy'ing to a non-8-byte-aligned uint64 *.
Attached patch fixes it by simplifying the _Final code and
getting rid of the pointer.
(I redefined
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
NetBSD 1.6 with older OpenSSL. OpenSSL 0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher.
And the AES tests fails anyway. I guess it can stay as expected
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
NetBSD 1.6 with older OpenSSL. OpenSSL 0.9.7 does not have
AES, but most of PGP tests use it as it is the preferred cipher.
On Mon, Jul 11, 2005 at 02:59:54PM +0300, Marko Kreen wrote:
On Mon, Jul 11, 2005 at 05:50:32AM -0500, Andrew Dunstan wrote:
Marko Kreen said:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2005-07-11%2002:30:00
NetBSD 1.6 with older OpenSSL. OpenSSL 0.9.7 does not have
Marko Kreen marko@l-t.ee writes:
Result is - it's not so bad. As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.
Looks good, but I'm still getting these compile warnings:
openssl.c: In function `ossl_des3_ecb_encrypt':
openssl.c:484:
Marko Kreen marko@l-t.ee writes:
(I redefined bzero and bcopy but now I think they should be
replaced directly - patch later.)
Please. We do not use those old functions in the Postgres code;
memcpy, memmove, memset, etc are the project standard.
regards, tom lane
On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Result is - it's not so bad. As I used rijndael.c to provide
OpenSSL's own interface, I even got rid of all the ifdefs inside
the code.
Looks good, but I'm still getting these compile warnings:
On Mon, Jul 11, 2005 at 10:13:22AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
(I redefined bzero and bcopy but now I think they should be
replaced directly - patch later.)
Please. We do not use those old functions in the Postgres code;
memcpy, memmove, memset, etc are the
Marko Kreen marko@l-t.ee writes:
On Mon, Jul 11, 2005 at 10:10:12AM -0400, Tom Lane wrote:
The following addition to the patch shuts up gcc with openssl 0.9.7a,
but I'm not sure if it will break anything with older openssl ---
comments?
They won't matter on older OpenSSL, as the macros will
Marko Kreen marko@l-t.ee writes:
New sha2 code on Solaris 2.8 / SPARC. Seems like it has
problems memcpy'ing to a non-8-byte-aligned uint64 *.
...
Attached patch includes sys/param.h, where I found them on
MINGW, and puts stricter checks into all files.
Applied.
On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:
void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
On Mon, Jul 11, 2005 at 11:09:06AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
New sha2 code on Solaris 2.8 / SPARC. Seems like it has
problems memcpy'ing to a non-8-byte-aligned uint64 *.
...
Attached patch includes sys/param.h, where I found them on
MINGW, and puts
On Mon, Jul 11, 2005 at 09:19:37AM -0600, Michael Fuhr wrote:
On Mon, Jul 11, 2005 at 10:39:26AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
They won't matter on older OpenSSL, as the macros will recast
again. But on 0.9.7e the signature is:
void DES_ecb3_encrypt(const
Marko Kreen marko@l-t.ee writes:
Here is the bcopy, bzero removal patch.
Applied.
I'm seeing the following build failure on HPUX:
/usr/ccs/bin/ld +h libpgcrypto.sl.0 -b +b /home/postgres/testversion/lib
pgcrypto.o px.o px-hmac.o px-crypt.o misc.o crypt-gensalt.o crypt-blowfish.o
crypt-des.o
On Mon, Jul 11, 2005 at 06:41:35PM +0300, Marko Kreen wrote:
When I saw that only 0.9.7[efg] have new signature I even
considered macrofying that. But now with 0.9.8 again different
I really would like to not to touch it, as I have no idea which
one will be the stable signature.
Comments?
On Mon, Jul 11, 2005 at 11:46:29AM -0400, Tom Lane wrote:
Marko Kreen marko@l-t.ee writes:
Here is the bcopy, bzero removal patch.
Applied.
I'm seeing the following build failure on HPUX:
/usr/ccs/bin/ld +h libpgcrypto.sl.0 -b +b /home/postgres/testversion/lib
pgcrypto.o px.o
Another build failure from buildfarm. Seems like
I forgot to update win32 code when doing a renaming
in random.c
--
marko
Index: contrib/pgcrypto/random.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/random.c,v
retrieving
Marko Kreen marko@l-t.ee writes:
Another build failure from buildfarm. Seems like
I forgot to update win32 code when doing a renaming
in random.c
Applied.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you
Marko Kreen wrote:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04
Linking problem with zlib on Solaris 9/x86. I am clueless about
this. I can anyone look into it?
It appears to be finding the static /usr/local/lib/libz.a instead of the
dynamic
32 matches
Mail list logo
