From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <peter_e(at)gmx(dot)net>, <darcy(at)wavefire(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: buildfarm build failure: icc7 + --enable-cassert |
Date: | 2004-12-12 19:25:03 |
Message-ID: | 1113.24.211.141.25.1102879503.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane said:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Darcy Buskermolen wrote:
>>> It looks like --enable-cassert isn't handled properly under icc7
>>>
>>>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2004-12-07%2016:30:44>
>> That is quite a superficial display of the issue. If you want to get
>> to the bottom of this, you need to, uh, dig deeper.
>
> This looks to me like a standard incompatible-version-of-shared-library
> issue, specifically, the .so was built with --enable-cassert but the
> backend trying to load it was not. Andrew claims he's designed the
> buildfarm test sequence to prevent that sort of problem (by deleting
> the previous installation before doing "make check") but I think he
> musta missed something.
>
*smile*
I've been fairly careful, even paranoid, about avoiding conflicts.
The perl code that runs before we even try to check out the code, much less
build or install anything, is this:
die "$buildroot/$branch has $pgsql or inst directories!"
if (-d $pgsql || -d "inst");
inst is the install target.
Far more likely is that we are getting a conflict with a *NON* buildfarm
install.
Maybe we need to look at some rpath settings?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-12 19:43:26 | Re: buildfarm build failure: icc7 + --enable-cassert |
Previous Message | Tom Lane | 2004-12-12 19:05:31 | Re: buildfarm build failure: icc7 + --enable-cassert |