Horton

Thread

  1. Re: 4 pgcrypto regressions failures - 1 unsolved

    Andrew Dunstan <andrew@dunslane.net> — 2005-07-11T10:50:32Z

    Marko Kreen said:
>

>
>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=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
> failure.
>

Please try to avoid expected failures if possible. If you must have them,
move them into a test file of their own. Consider the possibility of using
alternative .out files.

This doesn't matter to Buildfarm quite so much for contrib as it does for
main or PL regression sets, as contrib is the last thing checked, so a
failure there doesn't block any other steps in the checking process. Still,
a contrib failure will show up as yellow rather than green.

Buildfarm does not currently have a way of knowing what failure is expected
and what is not - it currently treats any regression failure as unexpected.
Changing that is on my TODO list, but it's not going to happen any time soon.

cheers

andrew

  2. 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T10:54:21Z

    http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=potorooo&dt=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 bzero and bcopy but now I think they should be
replaced directly - patch later.)



http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=goose&dt=2005-07-11%2006:00:04
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ferret&dt=2005-07-10%2018:25:11

The new sha2.c checks not only whether BYTE_ENDIAN is
LITTLE_ENDIAN or BIG_ENDIAN but also whether it is set.
And the test fails on both Cygwin and MINGW.

As gcc evaluates "#if UNDEF1 == UNDEF2" as true and there
were no compile failures reported with current code, that
means currently internal AES, SHA1 and MD5 used randomly
big-endian, little-endian or both variants of code.

If there was no regression failures on those platforms,
it must be only by dumb luck.

Attached patch includes sys/param.h, where I found them on
MINGW, and puts stricter checks into all files.

After I see successful run in pgbuildfarm, I send it for
stable branches too.



http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canary&dt=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
failure.



http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonfly&dt=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?

Error message:
ld: fatal: relocations remain against allocatable but non-writable sections


-- 
marko

  3. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T11:59:54Z

    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=canary&dt=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
> > failure.
> 
> Please try to avoid expected failures if possible. If you must have them,
> move them into a test file of their own. Consider the possibility of using
> alternative .out files.

I need either to use included rijndael.c for AES with older
OpenSSL or rerun all tests to be Blowfish-only.

I want to standardise on AES so the former is preferred.

Now there's a choice:

1. Check OpenSSL version in main configure
2. #include "rijndael.c" in openssl.c

I guess 1. is nicer.  I try to hack something together.

-- 
marko

  4. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T13:13:28Z

    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=canary&dt=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
> > > failure.
> > 
> > Please try to avoid expected failures if possible. If you must have them,
> > move them into a test file of their own. Consider the possibility of using
> > alternative .out files.
> 
> I need either to use included rijndael.c for AES with older
> OpenSSL or rerun all tests to be Blowfish-only.
> 
> I want to standardise on AES so the former is preferred.
> 
> Now there's a choice:
> 
> 1. Check OpenSSL version in main configure
> 2. #include "rijndael.c" in openssl.c
> 
> I guess 1. is nicer.  I try to hack something together.

I tried 1. but that was messing with main build system for no
good reason.  As the openssl.c would still be mess, so I went
with 2.

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.

-- 
marko

  5. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-11T14:10:12Z

    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: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c:484: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c: In function `ossl_des3_ecb_decrypt':
openssl.c:498: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
openssl.c:498: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type

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?

			regards, tom lane


*** /home/postgres/pgsql/contrib/pgcrypto/openssl.c	Sun Jul 10 12:35:38 2005
--- new/openssl.c	Mon Jul 11 10:06:30 2005
***************
*** 446,452 ****
  	ossldata   *od = c->ptr;
  
  	for (i = 0; i < dlen / bs; i++)
! 		DES_ecb3_encrypt(data + i * bs, res + i * bs,
  						 &od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 1);
  	return 0;
  }
--- 480,487 ----
  	ossldata   *od = c->ptr;
  
  	for (i = 0; i < dlen / bs; i++)
! 		DES_ecb3_encrypt((const_DES_cblock *) (data + i * bs),
! 						 (DES_cblock *) (res + i * bs),
  						 &od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 1);
  	return 0;
  }
***************
*** 460,466 ****
  	ossldata   *od = c->ptr;
  
  	for (i = 0; i < dlen / bs; i++)
! 		DES_ecb3_encrypt(data + i * bs, res + i * bs,
  						 &od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 0);
  	return 0;
  }
--- 495,502 ----
  	ossldata   *od = c->ptr;
  
  	for (i = 0; i < dlen / bs; i++)
! 		DES_ecb3_encrypt((const_DES_cblock *) (data + i * bs),
! 						 (DES_cblock *) (res + i * bs),
  						 &od->u.des3.k1, &od->u.des3.k2, &od->u.des3.k3, 0);
  	return 0;
  }

  6. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-11T14:13:22Z

    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

  7. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T14:22:39Z

    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:
> 
> openssl.c: In function `ossl_des3_ecb_encrypt':
> openssl.c:484: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
> openssl.c:484: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type
> openssl.c: In function `ossl_des3_ecb_decrypt':
> openssl.c:498: warning: passing arg 1 of `DES_ecb3_encrypt' from incompatible pointer type
> openssl.c:498: warning: passing arg 2 of `DES_ecb3_encrypt' from incompatible pointer type
> 
> 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 recast
again.  But on 0.9.7e the signature is:

void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
              DES_key_schedule *ks1,DES_key_schedule *ks2,
              DES_key_schedule *ks3, int enc);

so it seems to me that with your patch the warnings will appear
on newer OpenSSL.  (Confirmed)

-- 
marko

  8. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T14:27:02Z

    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 project standard.

Indeed.  But I'll wait until the previous sha2 patch is applied
as they would conflict.

-- 
marko

  9. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-11T14:39:26Z

    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 recast
> again.  But on 0.9.7e the signature is:

> void DES_ecb3_encrypt(const unsigned char *input, unsigned char *output,
>               DES_key_schedule *ks1,DES_key_schedule *ks2,
>               DES_key_schedule *ks3, int enc);

> so it seems to me that with your patch the warnings will appear
> on newer OpenSSL.  (Confirmed)

Grumble --- you're right.  It's probably not worth ifdef'ing the code to
suppress the warnings on 0.9.7a ...

			regards, tom lane

  10. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-11T15:09:06Z

    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.

			regards, tom lane

  11. Re: 4 pgcrypto regressions failures - 1 unsolved

    Michael Fuhr <mike@fuhr.org> — 2005-07-11T15:19:37Z

    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,
> >               DES_key_schedule *ks1,DES_key_schedule *ks2,
> >               DES_key_schedule *ks3, int enc);
> 
> > so it seems to me that with your patch the warnings will appear
> > on newer OpenSSL.  (Confirmed)
> 
> Grumble --- you're right.  It's probably not worth ifdef'ing the code to
> suppress the warnings on 0.9.7a ...

Hmmm...in 0.9.8 the signature is back to what it was in 0.9.7[a-d]:

void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output,
                      DES_key_schedule *ks1,DES_key_schedule *ks2,
                      DES_key_schedule *ks3, int enc);

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

  12. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T15:26:03Z

    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 stricter checks into all files.
> 
> Applied.

I see you also cleaned the includes.  Thanks.

Here is the bcopy, bzero removal patch.

-- 
marko

  13. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T15:41:35Z

    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 unsigned char *input, unsigned char *output,
> > >               DES_key_schedule *ks1,DES_key_schedule *ks2,
> > >               DES_key_schedule *ks3, int enc);
> > 
> > > so it seems to me that with your patch the warnings will appear
> > > on newer OpenSSL.  (Confirmed)
> > 
> > Grumble --- you're right.  It's probably not worth ifdef'ing the code to
> > suppress the warnings on 0.9.7a ...
> 
> Hmmm...in 0.9.8 the signature is back to what it was in 0.9.7[a-d]:
> 
> void DES_ecb3_encrypt(const_DES_cblock *input, DES_cblock *output,
>                       DES_key_schedule *ks1,DES_key_schedule *ks2,
>                       DES_key_schedule *ks3, int enc);

Ugh.  As I see the old signature goes up to 0.9.7d, and only
0.9.7[e,f,g] have the new signature.

0.9.7e is released on Oct 2004.  There is a chance that the 0.9.8 serie
was branched before that and later 0.9.8x releases will also
change signature.  Or the change was mistake, and it was
reversed in 0.9.8 - but then why release 0.9.7[f,g] with new
signature?

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?

-- 
marko

  14. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-11T15:46:29Z

    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 crypt-md5.o  md5.o sha1.o sha2.o internal.o blf.o rijndael.o fortuna.o random.o pgp-mpi-internal.o mbuf.o pgp.o pgp-armor.o pgp-cfb.o pgp-compress.o pgp-decrypt.o pgp-encrypt.o pgp-info.o pgp-mpi.o pgp-pubdec.o pgp-pubenc.o pgp-pubkey.o pgp-s2k.o pgp-pgsql.o -L../../src/port  `gcc -L../../src/port  -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib -print-libgcc-file-name`  -lz -o libpgcrypto.sl.0
/usr/ccs/bin/ld: Can't find library for -lz
make: *** [libpgcrypto.sl.0] Error 1

I believe the issue is that libz.sl is in /usr/local/lib/, which is not
searched by default by HP's linker.  It *is* searched by default by gcc,
which is why -lz works without any explicit -L in the pg_dump/pg_restore
builds.  But here we are invoking a different tool with a different
default search path.

Possibly there's something similar happening on that Solaris buildfarm
machine?

			regards, tom lane

  15. Re: 4 pgcrypto regressions failures - 1 unsolved

    Michael Fuhr <mike@fuhr.org> — 2005-07-11T15:51:00Z

    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?

Sounds like a question for the OpenSSL developers.  If a search
through their list archives or CVS repository doesn't yield the
answer, then maybe asking the question on one of their lists will.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

  16. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T15:58:05Z

    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 px-hmac.o px-crypt.o misc.o crypt-gensalt.o crypt-blowfish.o crypt-des.o crypt-md5.o  md5.o sha1.o sha2.o internal.o blf.o rijndael.o fortuna.o random.o pgp-mpi-internal.o mbuf.o pgp.o pgp-armor.o pgp-cfb.o pgp-compress.o pgp-decrypt.o pgp-encrypt.o pgp-info.o pgp-mpi.o pgp-pubdec.o pgp-pubenc.o pgp-pubkey.o pgp-s2k.o pgp-pgsql.o -L../../src/port  `gcc -L../../src/port  -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib -print-libgcc-file-name`  -lz -o libpgcrypto.sl.0
> /usr/ccs/bin/ld: Can't find library for -lz
> make: *** [libpgcrypto.sl.0] Error 1
> 
> I believe the issue is that libz.sl is in /usr/local/lib/, which is not
> searched by default by HP's linker.  It *is* searched by default by gcc,
> which is why -lz works without any explicit -L in the pg_dump/pg_restore
> builds.  But here we are invoking a different tool with a different
> default search path.
> 
> Possibly there's something similar happening on that Solaris buildfarm
> machine?

No, there it finds the libz (in /usr/local/lib - the link command
is gcc with -L/usr/local/lib), but in not satisfied with .. something.

-- 
marko

  17. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-11T16:43:33Z

    Another build failure from buildfarm.  Seems like
I forgot to update win32 code when doing a renaming
in random.c

-- 
marko

  18. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-11T17:00:28Z

    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

  19. Re: 4 pgcrypto regressions failures - 1 unsolved

    Kris Jurka <books@ejurka.com> — 2005-07-11T23:47:18Z

    Marko Kreen wrote:

> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonfly&dt=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 /usr/lib/libz.so.

Kris Jurka

  20. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-12T07:28:17Z

    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=dragonfly&dt=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 /usr/lib/libz.so.

So it is a local problem?  I see that the configure line contains:
"--with-includes=/usr/local/include --with-libs=/usr/local/lib"
explicitly.

-- 
marko

  21. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-12T09:51:44Z

    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 not update IV buffer.
- As the previous mistake was not picked up by current
  regression tests, I added a 'longer than a block'
  test to all ciphers.

-- 
marko

  22. Re: 4 pgcrypto regressions failures - 1 unsolved

    Kris Jurka <books@ejurka.com> — 2005-07-12T18:06:46Z

    
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=dragonfly&dt=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 /usr/lib/libz.so.
> 
> So it is a local problem?  I see that the configure line contains:
> "--with-includes=/usr/local/include --with-libs=/usr/local/lib"
> explicitly.
> 

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.

Kris Jurka

  23. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-12T19:51:58Z

    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 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 not update IV buffer.
> - As the previous mistake was not picked up by current
>   regression tests, I added a 'longer than a block'
>   test to all ciphers.
> 
> -- 
> marko

  24. Re: 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-12T20:29:09Z

    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 that the wrapper macros for CBC mode
>   do not update IV buffer.
> - As the previous mistake was not picked up by current
>   regression tests, I added a 'longer than a block'
>   test to all ciphers.

Applied, thanks.

			regards, tom lane

  25. Re: 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-15T17:20:38Z

    [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 found two suggestions:

1. http://curl.haxx.se/mail/lib-2002-01/0092.html
   (Use -mimpure-text on linking line)

2. http://www.filibeto.org/pipermail/solaris-users/2004-March/000662.html
   (that using GNU ld not Sun's fixes it)

The attached patch does #1.  Could you try it and see if it fixes it?

-- 
marko

  26. Re: 4 pgcrypto regressions failures - 1 unsolved

    Kris Jurka <books@ejurka.com> — 2005-07-16T01:06:15Z

    
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 
> > libpgcrypto.so while gcc refuses to.
> 
> 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)
> 
> The attached patch does #1.  Could you try it and see if it fixes it?
> 

This patch works, pgcrypto links and passes its installcheck test now.

Kris Jurka

  27. Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

    Marko Kreen <marko@l-t.ee> — 2005-07-16T10:07:41Z

    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 compiler and it works fine.  It links all of libz.a into 
> > > libpgcrypto.so while gcc refuses to.
> > 
> > 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)
> > 
> > The attached patch does #1.  Could you try it and see if it fixes it?
> > 
> 
> This patch works, pgcrypto links and passes its installcheck test now.
> 
> Kris Jurka

Thanks.

Here is the patch with a little comment.

It should not break anything as it just disables a extra
argument "-assert pure-text" to linker.

Linking static libraries into shared one is bad idea, as the
static parts wont be shared between processes, but erroring
out is worse, especially if another compiler for a platform
allows it.

This makes gcc act same way as Sun's cc.

-- 
marko

  28. Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-16T14:54:57Z

    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 bit and found two suggestions:
> 
> 1. http://curl.haxx.se/mail/lib-2002-01/0092.html
> (Use -mimpure-text on linking line)
> 
> The attached patch does #1.  Could you try it and see if it fixes it?

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?

			regards, tom lane

  29. Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

    Kris Jurka <books@ejurka.com> — 2005-07-16T15:22:10Z

    
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 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 and libz.a is in /usr/local/lib 
while libz.so is in /usr/lib.

Kris Jurka

  30. Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-16T16:15:08Z

    Kris Jurka <books@ejurka.com> 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 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 reason for the .so and .a versions of a
library to live in different places.  We certainly shouldn't hack our
build process to build deliberately-inefficient object files in order to
accommodate such a setup.

			regards, tom lane

  31. Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

    Kris Jurka <books@ejurka.com> — 2005-07-16T17:37:05Z

    
On Sat, 16 Jul 2005, Tom Lane wrote:

> Kris Jurka <books@ejurka.com> 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 reason for the .so and .a versions of a
> library to live in different places.  We certainly shouldn't hack our
> build process to build deliberately-inefficient object files in order to
> accommodate such a setup.
> 

Well the OS only came with the shared library and I needed the static one
for some reason, so I installed it alone under /usr/local.  This works 
fine with Sun's cc and Marko's research indicates that this will also 
work fine using GNU ld instead of Sun's ld.  This is certainly an unusual 
thing to do, but I don't believe it is a flat-out configuration error, 
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.

Kris Jurka

  32. Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved

    Tom Lane <tgl@sss.pgh.pa.us> — 2005-07-16T18:06:07Z

    Kris Jurka <books@ejurka.com> 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 to libz unless a shared libz is available (compare for instance the
situation with plperl and an unshared libperl).  However, I'm not sure
that we could reasonably expect to make a configuration test that would
detect a situation like this --- that is, if we did look for shared
libz, we would find it, and the fact that a nonshared libz in a
different place would cause the actual link to fail seems like something
that configure would be unlikely to be able to realize.

I'm still of the opinion that your libz installation is broken; the fact
that some other products chance not to fail with it is not evidence that
it's OK.  You could for instance have installed both libz.a and libz.so
from the same build in /usr/local/lib, and that would work fine,
independently of the existence of a version in /usr/lib.

Come to think of it, are you sure that the versions in /usr/lib and
/usr/local/lib are even ABI-compatible?  If they are from different zlib
releases, I think you're risking trouble regardless.  Really the right
way to deal with this sort of thing is that you put libz.a and libz.so
in /usr/local/lib and corresponding headers in /usr/local/include, and
then you don't need to sweat whether they are exactly compatible with
what appears in /usr/lib and /usr/include.

			regards, tom lane