Re: [HACKERS] pg_regress breaks on msys
Hi Tom-san. This is very strange.!! $ make -s In file included from preproc.y:6668: pgc.c: In function `yylex': pgc.c:1539: warning: label `find_rule' defined but not used C:/MinGW/include/ctype.h: At top level: pgc.c:3724: warning: `yy_flex_realloc' defined but not used initdb.c: In function `locale_date_order': initdb.c:2163: warning: `%x' yields only last 2 digits of year in some locales pg_backup_tar.c: In function `_tarAddFile': pg_backup_tar.c:1052: warning: comparison is always false due to limited range of data type All of PostgreSQL successfully made. Ready to install. $ make check make -C ../../../src/port all make[1]: Entering directory `/home/hi-saito/postgresql-8.2devel-20060720/src/port' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/hi-saito/postgresql-8.2devel-20060720/src/port' make -C ../../../contrib/spi refint.dll autoinc.dll make[1]: Entering directory `/home/hi-saito/postgresql-8.2devel-20060720/contrib/spi' make[1]: `refint.dll' is up to date. make[1]: `autoinc.dll' is up to date. make[1]: Leaving directory `/home/hi-saito/postgresql-8.2devel-20060720/contrib/spi' rm -rf ./testtablespace mkdir ./testtablespace ./pg_regress --temp-install=./tmp_check --top-builddir=../../.. --temp-port=55432 --schedule=./parallel_schedule --multibyte=SQL_ASCII --load-language=plpgsql == creating temporary installation== == initializing database system == == starting postmaster== running on port 55432 with pid 1964 == creating database regression == CREATE DATABASE ALTER DATABASE == installing plpgsql == CREATE LANGUAGE == running regression test queries== parallel group (13 tests): text oid varchar char name float4 int2 boolean int8 int4 float8 bit numeric boolean ... ok char ... diff command failed with status 1: diff -w ./expected/char.out ./results/char.out ./results/char.diff server stopped make: *** [check] Error 2 However, $ ls -l results/char.diff ls: results/char.diff: No such file or directory Um $ diff -w ./expected/char.out ./results/char.out 66d65 | A 71c70 (5 rows) --- (4 rows) 79d77 | A 84c82 (6 rows) --- (5 rows) 90a89 | A 92c91 (1 row) --- (2 rows) 99a99 | A 101c101 (2 rows) --- (3 rows) $ diff -w ./expected/char.out ./results/char.out ./results/char.diff $ ls -l results/char.diff -rw-r--r--1 hi-saito pgsql 204 Jul 20 15:23 results/char.diff [EMAIL PROTECTED] ~/postgresql-8.2devel-20060720/src/test/regress $ cat results/char.diff 66d65 | A 71c70 (5 rows) --- (4 rows) 79d77 | A 84c82 (6 rows) --- (5 rows) 90a89 | A 92c91 (1 row) --- (2 rows) 99a99 | A 101c101 (2 rows) --- (3 rows) Futhermore, tracking is required. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_regress breaks on msys
Hiroshi Saito [EMAIL PROTECTED] writes: This is very strange.!! boolean ... ok char ... diff command failed with status 1: diff -w ./expected/char.out ./results/char.out ./results/char.diff server stopped Yes, I believe the problem is that our Windows versions of the WIFEXITED/WEXITSTATUS macros are wrong. pg_regress is trying to verify that the diff call didn't fail entirely (eg, diff not there or failed to read one of the files), but the status code diff is returning for files not the same is confusing it. Can anyone check into what the result status conventions really are on Windows? I am tempted to change the macros to just swap the bytes, but I dunno what that will do to their existing usages to check the result of pclose() or win32_waitpid(). regards, tom lane ---(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] pg_regress breaks on msys
From: Tom Lane Hiroshi Saito [EMAIL PROTECTED] writes: This is very strange.!! boolean ... ok char ... diff command failed with status 1: diff -w ./expected/char.out ./results/char.out ./results/char.diff server stopped Yes, I believe the problem is that our Windows versions of the WIFEXITED/WEXITSTATUS macros are wrong. pg_regress is trying to verify that the diff call didn't fail entirely (eg, diff not there or failed to read one of the files), but the status code diff is returning for files not the same is confusing it. Probably No, I also suspected it in the beginning. However, char.diff was not created by some strange condition. I think that WIFEXITED showed the strange condition. In the place which I showed above, diff makes char.diff from the Manual operation. I expect that it is related to a system() call. I am investigating in some other environments. now... However, It does not clarify yet..:-( Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: pg_regress now seems to break on Msys virtual locations: Example from the buildfarm: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=snakedt=2006-07-19%2009:00:00 == pgsql.4660/src/test/regress/log/initdb.log === The filename, directory name, or volume label syntax is incorrect. Surely this was tested when the original was prepared? You can probably blame me instead of Magnus, because I did extensive fooling with the quoting of the commands issued by pg_regress ... and no, I don't have msys to test with, that's what the buildfarm is for ;-) Neither do I right now. This error message seems pretty thoroughly unhelpful though. Any ideas what it's unhappy about? I think we need to change the pg_regress error messages so that it includes the command string that failed, at least for now. Then we might know instead of speculating. It will be either quoting problem or a vitual path problem, I am pretty sure. The old shell script ran in a bourne-shell-like manner. But calling system() from a C program will call the Windows command shell, where the quoting rules are quite different. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_regress breaks on msys
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: This error message seems pretty thoroughly unhelpful though. Any ideas what it's unhappy about? I think we need to change the pg_regress error messages so that it includes the command string that failed, at least for now. Done, but I bet it doesn't tell us anything we don't know already. It will be either quoting problem or a vitual path problem, I am pretty sure. The old shell script ran in a bourne-shell-like manner. But calling system() from a C program will call the Windows command shell, where the quoting rules are quite different. In src/include/port.h we have /* * Win32 needs double quotes at the beginning and end of system() * strings. If not, it gets confused with multiple quoted strings. * It also requires double-quotes around the executable name and * any files used for redirection. Other args can use single-quotes. * * See the Notes section about quotes at: * http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM */ The referenced link seems to be dead :-( but AFAICS the pg_regress code is following the stated rules. Also, how is it getting past the make install step which is quoting things just the same? Puzzling. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_regress breaks on msys
Bruce Momjian [EMAIL PROTECTED] writes: * From http://www.computerhope.com/cmd.htm: * * 1. If all of the following conditions are met, then quote characters * on the command line are preserved: * * - no /S switch * - exactly two quote characters * - no special characters between the two quote characters, where special * is one of: ()@^| * - there are one or more whitespace characters between the the two quote * characters * - the string between the two quote characters is the name of an * executable file. Hmm, that suggests that our code works *only* if there's white space in all the paths !? Seems unlikely that this description is fully correct, or we'd have had problems before. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: * From http://www.computerhope.com/cmd.htm: * * 1. If all of the following conditions are met, then quote characters * on the command line are preserved: * * - no /S switch * - exactly two quote characters * - no special characters between the two quote characters, where special * is one of: ()@^| * - there are one or more whitespace characters between the the two quote * characters * - the string between the two quote characters is the name of an * executable file. Hmm, that suggests that our code works *only* if there's white space in all the paths !? Seems unlikely that this description is fully correct, or we'd have had problems before. It is saying _all_ these have to be true, and we already quote executables, and the string, so we always have more than two quotes: * Win32 needs double quotes at the beginning and end of system() * strings. If not, it gets confused with multiple quoted strings. * It also requires double-quotes around the executable name and * any files used for redirection. Other args can use single-quotes. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_regress breaks on msys
Bruce Momjian [EMAIL PROTECTED] writes: Hmm, that suggests that our code works *only* if there's white space in all the paths !? Seems unlikely that this description is fully correct, or we'd have had problems before. It is saying _all_ these have to be true, and we already quote executables, and the string, so we always have more than two quotes: Well, the description is about as clear as mud, because it's not saying which two quote characters it's talking about. I read it as talking about the two quote characters around any one word/pathname. If you think it's talking about the two quote characters we put around the whole command (the SYSTEMQUOTE dodge), then we're certainly going to fail the no special characters test, because all these commands use I/O redirection symbols. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: This error message seems pretty thoroughly unhelpful though. Any ideas what it's unhappy about? I think we need to change the pg_regress error messages so that it includes the command string that failed, at least for now. Done, but I bet it doesn't tell us anything we don't know already. Well, we have a result, courtesy of a special run from Stefan: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorsedt=2006-07-19%2017:52:41 has: Command was: C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/bin/initdb -D C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/data -L C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql --noclean --no-locale ./log/initdb.log 21 The second C:/msys/1.0/ should not be in the path to initdb. Not sure how to fix. cheers andrew It will be either quoting problem or a vitual path problem, I am pretty sure. The old shell script ran in a bourne-shell-like manner. But calling system() from a C program will call the Windows command shell, where the quoting rules are quite different. In src/include/port.h we have /* * Win32 needs double quotes at the beginning and end of system() * strings. If not, it gets confused with multiple quoted strings. * It also requires double-quotes around the executable name and * any files used for redirection. Other args can use single-quotes. * * See the Notes section about quotes at: * http://home.earthlink.net/~rlively/MANUALS/COMMANDS/C/CMD.HTM */ The referenced link seems to be dead :-( but AFAICS the pg_regress code is following the stated rules. Also, how is it getting past the make install step which is quoting things just the same? Puzzling. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_regress breaks on msys
After looking at the presumably-working uses of system() in initdb and pg_ctl, I have a theory about the pg_regress problem --- could it be that Windows system() requires a space between I/O redirection symbols and pathnames? I see that the pre-existing code consistently puts one, except in cases like 21: snprintf(cmd, MAXPGPATH, %s\%s\ %s%s \%s\ \%s\ 21 %s, SYSTEMQUOTE, postgres_path, pgdata_opt, post_opts, DEVNULL, log_file, SYSTEMQUOTE); but there's nothing in our docs saying this is necessary ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Hmm, that suggests that our code works *only* if there's white space in all the paths !? Seems unlikely that this description is fully correct, or we'd have had problems before. It is saying _all_ these have to be true, and we already quote executables, and the string, so we always have more than two quotes: Well, the description is about as clear as mud, because it's not saying which two quote characters it's talking about. I read it as talking about the two quote characters around any one word/pathname. If you think it's talking about the two quote characters we put around the whole command (the SYSTEMQUOTE dodge), then we're certainly going to fail the no special characters test, because all these commands use I/O redirection symbols. Right, the top says: * 1. If all of the following conditions are met, then quote characters * on the _command_ _line_ are preserved: It is talking about the entire command string, because this is system() and there is no distinction between commands and arguments --- it is one big string. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_regress breaks on msys
Andrew Dunstan [EMAIL PROTECTED] writes: Command was: C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/bin/initdb -D C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/data -L C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql --noclean --no-locale ./log/initdb.log 21 The second C:/msys/1.0/ should not be in the path to initdb. Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR after that instead of before it? What we need is a way to determine the paths that make install used ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_regress breaks on msys
Andrew Dunstan [EMAIL PROTECTED] writes: Well, we have a result, courtesy of a special run from Stefan: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorsedt= 2006-07-19%2017:52:41 has: Command was: C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test /regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbu ild/HEAD/inst/bin/initdb -D C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/ regress/./tmp_check/data -L C:/msys/1.0/home/pgbuild/pgfarmbuild/HEAD/pgsql.804/src/test/ regress/./tmp_check/install/C:/msys/1.0/home/pgbuild/pgfarmbui ld/HEAD/inst/share/postgresql --noclean --no-locale ./log/initdb.log 21 The second C:/msys/1.0/ should not be in the path to initdb. Andrew's on to something, I think. Colons are verboten anywhere in a filename except position 2, right after a drive letter. The path to postgresql later in the command will also have problems. Regards, Paul Bort ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_regress breaks on msys
I wrote: Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR after that instead of before it? What we need is a way to determine the paths that make install used ... AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir etc, for instance this is how initdb/Makefile installs initdb: $(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)' The evidence at hand says that this should produce exactly the same path string as pg_regress is then using to call initdb. So the question in my mind now is how come the make install step isn't failing. For that matter, this same path-construction technique was used by the shellscript... so how come it worked before? It would be simple enough to make pg_regress strip off a drive letter from the path strings it receives from the Makefile, but I'm not seeing a principled way to discover that the /msys/1.0/ part has to go. How are the makefiles managing to generate a different value of $(bindir) at install time than what was passed into pg_regress at build time? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: I wrote: Ah-hah, so apparently make install DESTDIR=foo somehow inserts DESTDIR after that instead of before it? What we need is a way to determine the paths that make install used ... AFAICS, the makefiles are just blindly concatenating DESTDIR with bindir etc, for instance this is how initdb/Makefile installs initdb: $(INSTALL_PROGRAM) initdb$(X) '$(DESTDIR)$(bindir)/initdb$(X)' The evidence at hand says that this should produce exactly the same path string as pg_regress is then using to call initdb. So the question in my mind now is how come the make install step isn't failing. For that matter, this same path-construction technique was used by the shellscript... so how come it worked before? It would be simple enough to make pg_regress strip off a drive letter from the path strings it receives from the Makefile, but I'm not seeing a principled way to discover that the /msys/1.0/ part has to go. How are the makefiles managing to generate a different value of $(bindir) at install time than what was passed into pg_regress at build time? regards, tom lane I think we'll need to have the makefile tell us what it thinks the cwd is, so if it's a virtual path we'll be able to use that. Compare the install log on the 8.1 branch (from our new buildfarm member bandicoot) here http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=bandicootdt=2006-07-19%2009%3A52%3A28stg=check with what seahorse is showing. Note that the install does not involve windows paths at all - just Msys virtual paths. But we do need to use Windows paths for the data files. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pg_regress breaks on msys
Andrew Dunstan [EMAIL PROTECTED] writes: I think we'll need to have the makefile tell us what it thinks the cwd is, so if it's a virtual path we'll be able to use that. I don't see where cwd enters into it. The thing I don't understand is that the value of the make variable $(bindir) is apparently changing. How can it, when it's been hard-wired into Makefile.global by configure? regards, tom lane ---(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] pg_regress breaks on msys
I wrote: I don't see where cwd enters into it. The thing I don't understand is that the value of the make variable $(bindir) is apparently changing. How can it, when it's been hard-wired into Makefile.global by configure? After some googling I gather that msys' make has been hacked to transform paths between actual Windows paths and virtual paths at what-they-think-are-strategic spots. If this is correct, then I think our problem is that the method I used to inject the values of $(bindir) and friends into pg_regress.c ends up supplying actual Windows paths, where we would much rather it supplied virtual paths. An alternative method I had considered using was to have pg_regress.c get the paths by #including pg_config_paths.h. Can anyone say whether pg_config_paths.h receives real or virtual paths when building under mingw? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: I wrote: I don't see where cwd enters into it. The thing I don't understand is that the value of the make variable $(bindir) is apparently changing. How can it, when it's been hard-wired into Makefile.global by configure? After some googling I gather that msys' make has been hacked to transform paths between actual Windows paths and virtual paths at what-they-think-are-strategic spots. If this is correct, then I think our problem is that the method I used to inject the values of $(bindir) and friends into pg_regress.c ends up supplying actual Windows paths, where we would much rather it supplied virtual paths. Unless it also lies on the echoed command line this seems an unconvincing explanation. The seahorse log says: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND -I/c/tcl/include -I../../../src/include/port/win32 '-DPGBINDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/bin' '-DLIBDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/lib' '-DPGSHAREDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql' '-DHOST_TUPLE=i686-pc-mingw32' '-DMAKEPROG=make' '-DSHELLPROG=/bin/sh.exe' -c -o pg_regress.o pg_regress.c If those -D values are not what it gets then that would be quite evil. We used to pass these values almost same way when we first did initdb in C, and I don't recall any such problems. We had: override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ -DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*) There is also this warning, by the way: pg_regress.c:63: warning: 'shellprog' defined but not used cheers andrew ---(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] pg_regress breaks on msys
Andrew Dunstan [EMAIL PROTECTED] writes: Unless it also lies on the echoed command line this seems an unconvincing explanation. The seahorse log says: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND -I/c/tcl/include -I../../../src/include/port/win32 '-DPGBINDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/bin' '-DLIBDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/lib' '-DPGSHAREDIR=/home/pgbuild/pgfarmbuild/HEAD/inst/share/postgresql' '-DHOST_TUPLE=i686-pc-mingw32' '-DMAKEPROG=make' '-DSHELLPROG=/bin/sh.exe' -c -o pg_regress.o pg_regress.c If those -D values are not what it gets then that would be quite evil. Indeed ... but if those *are* what it gets then how can you explain the constructed paths? I just committed a change to extract the paths via pg_config_paths.h. If that doesn't fix it then I guess the next thing is to put in some debug printout to show what values are really getting compiled in :-( We used to pass these values almost same way when we first did initdb in C, and I don't recall any such problems. We had: override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ -DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*) That seems a bit interesting. What are the stars for? I don't see anything about a syntax like that in my gmake documentation. There is also this warning, by the way: pg_regress.c:63: warning: 'shellprog' defined but not used Good catch, fix committed. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_regress breaks on msys
I wrote: I just committed a change to extract the paths via pg_config_paths.h. If that doesn't fix it then I guess the next thing is to put in some debug printout to show what values are really getting compiled in :-( Seems that *did* fix it, which opens a whole new set of questions about how much you can trust msys' make. However, the latest seahorse results show we still have a bug or two: oidjoins ... ok type_sanity ... ok opr_sanity ... ok test geometry ... server stopped diff command failed: diff -w ./expected/geometry.out ./results/geometry.out ./results/geometry.diff make: *** [check] Error 2 What I think happened here is that diff reported a difference and pg_regress misinterpreted the exit status as being a hard failure. Can someone check on whether it's possible to tell the difference between these cases with Windows diff ? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_regress breaks on msys
Tom Lane wrote: We used to pass these values almost same way when we first did initdb in C, and I don't recall any such problems. We had: override CPPFLAGS := -DPGBINDIR=\$(*bindir*)\ -DPGDATADIR=\$(*datadir*)\ -DFRONTEND -I$(*libpq_srcdir*) $(*CPPFLAGS*) That seems a bit interesting. What are the stars for? I don't see anything about a syntax like that in my gmake documentation. The stars are from my MUA not handling CP from formatted text as well as it should in text mode. It should have read: override CPPFLAGS := -DPGBINDIR=\$(bindir)\ -DPGDATADIR=\$(datadir)\ -DFRONTEND -I$(libpq_srcdir) $(CPPFLAGS) cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_regress breaks on msys
I wrote: What I think happened here is that diff reported a difference and pg_regress misinterpreted the exit status as being a hard failure. Can someone check on whether it's possible to tell the difference between these cases with Windows diff ? So the latest result shows that the return value from system() is in fact 1: type_sanity ... ok opr_sanity ... ok test geometry ... diff command failed with status 1: diff -w ./expected/geometry.out ./results/geometry.out ./results/geometry.diff server stopped What I am now wondering is why win32.h defines WIFEXITED and WEXITSTATUS the way it does. We have not previously been using those macros to test the result of system() --- at least not in any exercised code path --- and what I'm thinking is that they are flat out wrong. At least for testing system(). Are the results of GetExitCodeProcess() and pclose() really defined differently? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
