Re: buildfarm build failure: icc7 + --enable-cassert - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: buildfarm build failure: icc7 + --enable-cassert
Date
Msg-id 1113.24.211.141.25.1102879503.squirrel@www.dunslane.net
Whole thread Raw
In response to Re: buildfarm build failure: icc7 + --enable-cassert  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: buildfarm build failure: icc7 + --enable-cassert
List pgsql-hackers
Tom Lane said:
> Peter Eisentraut <peter_e@gmx.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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: buildfarm build failure: icc7 + --enable-cassert
Next
From: Tom Lane
Date:
Subject: Re: buildfarm build failure: icc7 + --enable-cassert