Thread: Re: [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
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