| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Kris Jurka <books(at)ejurka(dot)com> |
| Cc: | Marko Kreen <marko(at)l-t(dot)ee>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved |
| Date: | 2005-07-16 16:15:08 |
| Message-ID: | 1444.1121530508@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Kris Jurka <books(at)ejurka(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kris Jurka | 2005-07-16 17:37:05 | Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved |
| Previous Message | Kris Jurka | 2005-07-16 15:22:10 | Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2005-07-16 16:26:51 | Re: fixing REL7_3_STABLE build issues |
| Previous Message | Tom Lane | 2005-07-16 16:11:21 | Re: fixing REL7_3_STABLE build issues |