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
