Re: [PATCHES] 4 pgcrypto regressions failures - 1 unsolved - Mailing list pgsql-hackers

From Kris Jurka
Subject Re: [PATCHES] 4 pgcrypto regressions failures - 1 unsolved
Date
Msg-id Pine.BSO.4.56.0507161230380.1489@leary.csoft.net
Whole thread Raw
In response to Re: 4 pgcrypto regressions failures - 1 unsolved  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] 4 pgcrypto regressions failures - 1 unsolved  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 4 pgcrypto regressions failures - 1 unsolved
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] 4 pgcrypto regressions failures - 1 unsolved