Обсуждение: ECPG regression tests seem rather fundamentally broken

AFAICT, every buildfarm machine that runs ecpg tests has been failing
since Peter's patch here:
http://archives.postgresql.org/pgsql-committers/2007-01/msg00241.php

Now it looks to me like Peter was simply wrong: we do need to include
libpq because libecpg depends on it.  However, I tried reverting the
change and things still did not work.  The reason is that the test
programs are built with relative paths to libpq that look like../../../../../src/interfaces/libpq/libpq.sl.5
and then executed one level up from where they were built, causing
the relative path to be no good.  I suspect the only reason it has
been appearing to work for awhile is that people had usable copies
of libpq and perhaps libecpg installed in system-standard library
directories.  Take away those preinstalled libs, or render them
version-incompatible, and the ecpg tests stop working.
        regards, tom lane

Tom Lane wrote:
> AFAICT, every buildfarm machine that runs ecpg tests has been failing
> since Peter's patch here:
> http://archives.postgresql.org/pgsql-committers/2007-01/msg00241.php
>
> Now it looks to me like Peter was simply wrong: we do need to include
> libpq because libecpg depends on it.  However, I tried reverting the
> change and things still did not work.  The reason is that the test
> programs are built with relative paths to libpq that look like
>     ../../../../../src/interfaces/libpq/libpq.sl.5

This is a symptom specific to HP-UX, which hardcodes the link-time 
library path into the output.  The ECPG test probably never worked 
there.

> and then executed one level up from where they were built, causing
> the relative path to be no good.  I suspect the only reason it has
> been appearing to work for awhile is that people had usable copies
> of libpq and perhaps libecpg installed in system-standard library
> directories.  Take away those preinstalled libs, or render them
> version-incompatible, and the ecpg tests stop working.

I don't have any matching preinstalled libraries anywhere and I verified 
with ldd that it seems to look in the expected places for both 
libraries, and indeed the tests pass for me, so I don't know what's 
going on.
-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> ...  However, I tried reverting the
>> change and things still did not work.  The reason is that the test
>> programs are built with relative paths to libpq that look like
>> ../../../../../src/interfaces/libpq/libpq.sl.5

> This is a symptom specific to HP-UX, which hardcodes the link-time 
> library path into the output.  The ECPG test probably never worked 
> there.

Au contraire, it did work last time I tried (which I must admit was a
few months ago, so I cannot be sure just when we broke it).  And anyway,
how would you expect it to magically work differently on some other
platform, for a library that is neither present in the system's standard
search path, the rpath (which we failed to provide anyway), nor the
build-time-relative path?  I'm not quite sure what other plan the
dynamic linker should follow.
        regards, tom lane