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.phpNow 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