Thread: 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