Re: [HACKERS] Re: AW: Re: GiST for 7.1 !!
Tom Lane writes:
[EMAIL PROTECTED] writes:
on which configure didn't detect the absence of libz.so
Really? Details please. It's hard to see how it could have messed
up on that.
I didn't look well enough -- I apologize. The library is there, but
ld.so believes it is not:
typhoon postmaster
ld.so.1: postmaster: fatal: libz.so: open failed: No such file or directory
Killed
Odd. Can you show us the part of config.log that relates to zlib?
configure:4179: checking for zlib.h
configure:4189: gcc -E conftest.c /dev/null 2conftest.out
configure:4207: checking for inflate in -lz
configure:4226: gcc -o conftest conftest.c -lz -lgen -lnsl -lsocket -ldl -lm
-lreadline -ltermcap -lcurses 15
configure:4660: checking for crypt.h
This doesn't tell me much. But I modified configure to exit right
after this, without removing conftest*, and when I ran conftest it came
back with the same message:
typhoon ./conftest
ld.so.1: ./conftest: fatal: libz.so: open failed: No such file or directory
Killed
It's strange that configure's check to see if zlib is linkable should
succeed, only to have the live startup fail.
It is. In this line:
if { (eval echo configure:4226: \"$ac_link\") 15; (eval $ac_link) 25; } test -s
conftest${ac_exeext}; then
why is conftest tested for size instead of being executed?
Is it possible that
you ran configure with a different library search path (LD_LIBRARY_PATH
or local equivalent) than you are using now?
No, I didn't alter it. I am using the system-wide settings.
It's suspicious that the error message mentions libz.so when the actual
file name is libz.so.1, but I still don't see how that could result in
configure's link test succeeding but the executable not running.
That puzzles me as well. It seems to be because there is no libz.so on
the system. For if I do this:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/customer/selkovjr/lib
ln -s /usr/openwin/lib/libz.so.1 ~/lib/libz.so
the libz problem is gone, only to be followed by the next one:
typhoon ./conftest
ld.so.1: ./conftest: fatal: libreadline.so: open failed: No such file or directory
The odd thing is, there is no libreadline.so* on this system. Here's the corresponding
part of config.log:
configure:3287: checking for library containing readline
configure:3305: gcc -o conftest conftest.c -ltermcap -lcurses 15
Undefined first referenced
symbol in file
readline/var/tmp/ccxxiW3R.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 3294 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char readline();
int main() {
readline()
; return 0; }
configure:3327: gcc -o conftest conftest.c -lreadline -ltermcap -lcurses
15
This system is probaly badly misconfigured, but it would be great if
configure could see that. By the way, would you mind if I asked you to
log in and take a look? Is there a phone number where I can get you
with the password? I am not sure whether such tests could be of any
value, but it's the only Sun machine available to me for testing.
Thank you,
--Gene
Re: [HACKERS] Re: AW: Re: GiST for 7.1 !!
Tom Lane writes: [EMAIL PROTECTED] writes: ... SunOS typhoon 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-1 on which configure didn't detect the absence of libz.so Really? Details please. It's hard to see how it could have messed up on that. Tom, I didn't look well enough -- I apologize. The library is there, but ld.so believes it is not: typhoon postmaster ld.so.1: postmaster: fatal: libz.so: open failed: No such file or directory Killed This may very well be just my ISP's problem. Anyway, the details are: 1. My (relevant) environment: LD_LIBRARY_PATH=/usr/openwin/lib:/usr/lib:/usr/ucblib:/usr/ccs/lib PGLIB=/home/customer/selkovjr/pgsql/lib PGDATA=/home/customer/selkovjr/pgsql/data PATH=/usr/local/vendor/SUNWspro/bin:/usr/local/bin:/usr/local/gnu/bin:/usr/local/GNU/bin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/ucb:/etc:/usr/etc:/usr/openwin/bin:/home/customer/selkovjr/bin:./usr/local/bin::/home/customer/selkovjr/pgsql/bin 2. I built postgres (from the snapshot of Jan 13) with: ./configure --prefix=/home/customer/selkovjr/pgsql make make install 3. initdb worked. 4. The library in question is in /usr/openwin/lib: typhoon ls -l /usr/openwin/lib | grep libz -rwxr-xr-x 1 root bin97836 Sep 23 1999 libz.a -rwxr-xr-x 1 root bin70452 Sep 23 1999 libz.so.1 I can't think of anything else. Is there a one-liner to test libz? I believe I have successfully tested and run 6.5.3 in the same environment. --Gene
Re: [HACKERS] Re: AW: Re: GiST for 7.1 !!
[EMAIL PROTECTED] writes: on which configure didn't detect the absence of libz.so Really? Details please. It's hard to see how it could have messed up on that. I didn't look well enough -- I apologize. The library is there, but ld.so believes it is not: typhoon postmaster ld.so.1: postmaster: fatal: libz.so: open failed: No such file or directory Killed Odd. Can you show us the part of config.log that relates to zlib? It's strange that configure's check to see if zlib is linkable should succeed, only to have the live startup fail. Is it possible that you ran configure with a different library search path (LD_LIBRARY_PATH or local equivalent) than you are using now? It's suspicious that the error message mentions libz.so when the actual file name is libz.so.1, but I still don't see how that could result in configure's link test succeeding but the executable not running. regards, tom lane
Re: [HACKERS] Re: AW: Re: GiST for 7.1 !!
I am sorry I wasn't listening -- I may have helped by at least answering the direct questions and by testing. I have, in fact, positively tested both my and Oleg's code in the today's snapshot on a number of linux and FreeBSD systems. I failed on this one: SunOS typhoon 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-1 on which configure didn't detect the absence of libz.so I don't think my applications are affected by Oleg's changes. But I understand the tension that occurred during the past few days and even though I am now satisfied with the agreement you seem to have achieved, I could have hardly influenced it in any reasonable way. I am as sympathetic with the need for a smooth an solid code control as I am with promoting great features (or, in this case, just keeping a feature alive). So, if I were around at the time I was asked to vote, I wouldn't know how. I usually find it difficult to take sides in "Motherhood vs. Clean Air" debates. It is true that throwing a core during a regression test does gives one a black eye. It is also true that there are probably hundreds of possible users, ignorant of the GiST, trying to invent surrogate solutions. As far as I am concerned, I will be satisfied with whatever solution you arrive at. I am pleased that in this neighborhood, reason prevails over faith. --Gene
Re: [HACKERS] Re: AW: Re: GiST for 7.1 !!
[EMAIL PROTECTED] writes: I am sorry I wasn't listening -- I may have helped by at least answering the direct questions and by testing. I have, in fact, positively tested both my and Oleg's code in the today's snapshot on a number of linux and FreeBSD systems. I failed on this one: SunOS typhoon 5.7 Generic_106541-10 sun4u sparc SUNW,Ultra-1 on which configure didn't detect the absence of libz.so Really? Details please. It's hard to see how it could have messed up on that. regards, tom lane
[HACKERS] Re: AW: Re: GiST for 7.1 !!
IMHO, giving out real test results, even negative, instead of leaving things untested would be a honest thing to do. afaict there are several concerns or decisions, and we've made a few already: Re: gist.c patches... 1) Oleg and Hannu are committed to testing the repaired GiST as soon as it is in the main tree. They are both testing already with the patched version. 2) They will try to contact Gene to encourage testing with Gene's application, though they have no reason to suspect from their own testing that Gene's stuff will break. 3) There is a consensus that the gist.c patches should appear in the 7.1 release, to allow useful work with GiST and to enable further development. So it is OK to commit the gist.c patches based on Oleg's and Hannu's existing and future test plan. Re: regression tests... 4) We all would like to see some regression tests of GiST. Tom Lane has (rightly) expressed concern over unforeseen breakage in the regression flow when done on other platforms. 5) Oleg has some regression-capable test code available for contrib, but has indicated that fully (re)writing the regression tests will take too much time. 6) We have at least two committed testers for the 7.1 release for the GiST features. That is two more than we've ever had before (afacr Gene didn't participate in the end-stage beta cycle, but I may not be remembering correctly) so the risks that something is not right are greatly reduced, to below the risks of same on the day of release for previous versions. 8) Additional regression testing is required asap, but may not be allowed into the default 7.1 test sequence. How about adding an optional test a la "bigtest" for GiST for this release? It could go mainstream for 7.1.x or for 7.2 as we get more experience with it. This is just a suggestion and I'm sure there are other possibilities. I'm pretty sure we agree on most of points 1-8, and that 1-3 are resolved. Comments? - Thomas
Re: [HACKERS] Re: AW: Re: GiST for 7.1 !!
An optional test is like no test at all. No one runs optional tests. If the test is supposed to work then it should be mainstream. If the test might not work then you better go back and figure out what you're testing. If the test might not *compile* (which is probably the more severe problem that people are concerned about) then this idea won't help that at all unless you want to rework the regression test driver framework as well. I agree completely. This is just a transition phase to get GiST into the mainstream. - Thomas
