Re: buildfarm build failure: icc7 + --enable-cassert

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

In response to

Responses

Browse pgsql-hackers by date

  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