4 pgcrypto regressions failures - 1 unsolved

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: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

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

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

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

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

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

--
marko

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

Marko Kreen wrote:

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

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&amp;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

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

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&amp;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

Seems like down mail server ate first mail.

Here it is again.

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

[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

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

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

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

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