Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
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 Index: src/Makefile.shlib === RCS file: /opt/arc/cvs2/pgsql/src/Makefile.shlib,v retrieving revision 1.95 diff -u -c -r1.95 Makefile.shlib *** src/Makefile.shlib 13 Jul 2005 17:00:44 - 1.95 --- src/Makefile.shlib 16 Jul 2005 09:59:18 - *** *** 188,194 ifeq ($(PORTNAME), solaris) ifeq ($(GCC), yes) ! LINK.shared = $(CC) -shared else LINK.shared = $(CC) -G endif --- 188,196 ifeq ($(PORTNAME), solaris) ifeq ($(GCC), yes) ! # -mimpure-text disables passing '-assert pure-text' to linker, ! # to allow linking static library into shared one, like Sun's cc does. ! LINK.shared = $(CC) -shared -mimpure-text else LINK.shared = $(CC) -G endif ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
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 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
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 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
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 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
