Re: [HACKERS] ECPG regression tests seem rather fundamentally broken
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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ECPG regression tests seem rather fundamentally broken
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
