Thread: 4 pgcrypto regressions failures - 1 unsolved
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
Attachment
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
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
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
Attachment
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; }
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: > > 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
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:
> 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
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 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/
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
Attachment
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
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.ocrypt-blowfish.o crypt-des.o crypt-md5.o md5.o sha1.o sha2.o internal.o blf.o rijndael.o fortuna.o
random.opgp-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.opgp-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 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/
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.ocrypt-blowfish.o crypt-des.o crypt-md5.o md5.o sha1.o sha2.o internal.o blf.o rijndael.o fortuna.o random.opgp-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.opgp-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
Attachment
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&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&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
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
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
Attachment
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
Attachment
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
Attachment
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
Attachment
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
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
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
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