Horton

Thread

  1. mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-01-28T00:12:10Z

    With the attached patch I have managed to get Postgres built and running 
a clean set of regression tests using the Mingw64 toolset on my 64bit 
Windows7Pro machine.

There's lots of work still to do (lots of warnings to make go away, for 
example), but this is a pretty encouraging start.

It should also answer most of the questions XiaoboGu had about how to 
build the client libraries, since this falls out along the way.

NB: on Windows 7 you really need to build and run as a non-admin user. 
Windows blows away the PATH for your app otherwise. This took me a while 
to get to the bottom of.

cheers

andrew

  2. Re: mingw64

    Xiaobo Gu <guxiaobo1982@gmail.com> — 2011-01-28T01:23:07Z

    On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> With the attached patch I have managed to get Postgres built and running a
> clean set of regression tests using the Mingw64 toolset on my 64bit
> Windows7Pro machine.
>
> There's lots of work still to do (lots of warnings to make go away, for
> example), but this is a pretty encouraging start.
>
> It should also answer most of the questions XiaoboGu had about how to build
> the client libraries, since this falls out along the way.
>
> NB: on Windows 7 you really need to build and run as a non-admin user.
> Windows blows away the PATH for your app otherwise. This took me a while to
> get to the bottom of.
>

Hi andrew,
It's a great job you have done, but can you send me just the updated
files, because I don't have SVN set up, and not fimiliar with the SVN
commands. Thanks.

Xiaobo Gu

  3. Re: mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-01-28T01:35:58Z

    
On 01/27/2011 08:23 PM, Xiaobo Gu wrote:
> On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan<andrew@dunslane.net>  wrote:
>> With the attached patch I have managed to get Postgres built and running a
>> clean set of regression tests using the Mingw64 toolset on my 64bit
>> Windows7Pro machine.
>>
>> There's lots of work still to do (lots of warnings to make go away, for
>> example), but this is a pretty encouraging start.
>>
>> It should also answer most of the questions XiaoboGu had about how to build
>> the client libraries, since this falls out along the way.
>>
>> NB: on Windows 7 you really need to build and run as a non-admin user.
>> Windows blows away the PATH for your app otherwise. This took me a while to
>> get to the bottom of.
>>
> Hi andrew,
> It's a great job you have done, but can you send me just the updated
> files, because I don't have SVN set up, and not fimiliar with the SVN
> commands. Thanks.
>
>


We don't use SVN.

You can apply the patch with something like

    patch -p 1 < w64.patch

cheers

andrew

  4. Re: mingw64

    Xiaobo Gu <guxiaobo1982@gmail.com> — 2011-01-28T03:37:13Z

    On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
> With the attached patch I have managed to get Postgres built and running a
> clean set of regression tests using the Mingw64 toolset on my 64bit
> Windows7Pro machine.
>
> There's lots of work still to do (lots of warnings to make go away, for
> example), but this is a pretty encouraging start.
>
> It should also answer most of the questions XiaoboGu had about how to build
> the client libraries, since this falls out along the way.
>
> NB: on Windows 7 you really need to build and run as a non-admin user.
> Windows blows away the PATH for your app otherwise. This took me a while to
> get to the bottom of.
>

Hi
I am on my 32bit Windows XP SP3 now, using a non-admin user named postgres,
configure and make pass, but make install failed,

configure --without-zlib --host=x86_64-w64-mingw32
--with-system-tzdata=/usr/share/zoneinfo --prefix=D:/psqlbin
.....

$make

......


$ make install
D:/Amber/Devtool/MinGW64-1.0-20100913/bin/make -C src install
make[1]: Entering directory `d:/amber/devproj/postgresql-9.0.2/src'
/bin/mkdir -p 'D:/psqlbin/lib/postgresql/pgxs/src'
process_begin: CreateProcess(NULL, /bin/mkdir -p D:/psqlbin/lib/postgresql/pgxs/
src, ...) failed.
make (e=3): System can't find the specified path (translated from Chinese by me)
make[1]: *** [installdirs-local] Error 3
make[1]: Leaving directory `d:/amber/devproj/postgresql-9.0.2/src'
make: *** [install] Error 2


User postgres has full access previlige on D:/psqlbin directory

I'll try on my 64bit Win7 home basic later.

Xiaobo Gu

  5. Re: mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-01-28T03:44:42Z

    
On 01/27/2011 10:37 PM, Xiaobo Gu wrote:
>
> --with-system-tzdata=/usr/share/zoneinfo

Why on earth are you doing this on Windows? That's crazy. Did you run 
"make check"? You should always do that after a build before you install.

cheers

andrew

  6. Re: mingw64

    Xiaobo Gu <guxiaobo1982@gmail.com> — 2011-01-28T03:51:42Z

    On Fri, Jan 28, 2011 at 11:44 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 01/27/2011 10:37 PM, Xiaobo Gu wrote:
>>
>> --with-system-tzdata=/usr/share/zoneinfo
>
> Why on earth are you doing this on Windows? That's crazy. Did you run "make
> check"? You should always do that after a build before you install.
>

configure does not pass if I omit --with-system-tzdata=/usr/share/zoneinfo

Content of  config.log

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by PostgreSQL configure 9.0.2, which was
generated by GNU Autoconf 2.63.  Invocation command line was

  $ ./configure --without-zlib --host=x86_64-w64-mingw32 --prefix=D:/psqlbin

## --------- ##
## Platform. ##
## --------- ##

hostname = kzx-28F-tempdw
uname -m = i686
uname -r = 1.0.16(0.48/3/2)
uname -s = MINGW32_NT-5.1
uname -v = 2010-09-29 00:07

/usr/bin/uname -p = unknown
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: .
PATH: /usr/local/bin
PATH: /mingw/bin
PATH: /bin
PATH: /c/Program Files/Common Files/Microsoft Shared/Windows Live
PATH: /c/WINDOWS/system32
PATH: /c/WINDOWS
PATH: /c/WINDOWS/System32/Wbem
PATH: /c/PROGRA~1/IBM/CLIENT~1
PATH: /c/PROGRA~1/IBM/CLIENT~1/Shared
PATH: /c/PROGRA~1/IBM/CLIENT~1/Emulator
PATH: /c/Program Files/TortoiseSVN/bin
PATH: /c/Program Files/Common Files/Thunder Network/KanKan/Codecs
PATH: /d/Amber/Program/MIT/Kerberos/bin
PATH: .


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2069: checking build system type
configure:2087: result: i686-pc-mingw32
configure:2109: checking host system type
configure:2124: result: x86_64-w64-mingw32
configure:2148: checking which template to use
configure:2247: result: win32
configure:2354: checking whether to build with 64-bit integer date/time support
configure:2389: result: yes
configure:2396: checking whether NLS is wanted
configure:2430: result: no
configure:2438: checking for default port number
configure:2467: result: 5432
configure:2886: checking for block size
configure:2926: result: 8kB
configure:2938: checking for segment size
configure:2971: result: 1GB
configure:2983: checking for WAL block size
configure:3024: result: 8kB
configure:3036: checking for WAL segment size
configure:3077: result: 16MB
configure:3135: checking for x86_64-w64-mingw32-gcc
configure:3151: found /mingw/bin/x86_64-w64-mingw32-gcc
configure:3162: result: x86_64-w64-mingw32-gcc
configure:3240: checking for C compiler version
configure:3248: x86_64-w64-mingw32-gcc --version >&5
x86_64-w64-mingw32-gcc.exe (GCC) 4.5.2 20100913 (prerelease)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3252: $? = 0
configure:3259: x86_64-w64-mingw32-gcc -v >&5
Using built-in specs.
COLLECT_GCC=D:\Amber\Devtool\MinGW64-1.0-20100913\bin\x86_64-w64-mingw32-gcc.exe
COLLECT_LTO_WRAPPER=d:/amber/devtool/mingw64-1.0-20100913/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../build/gcc/src/configure
--target=x86_64-w64-mingw32
--prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--enable-languages=all,obj-c++ --enable-fully-dynamic-string
--disable-multilib
Thread model: win32
gcc version 4.5.2 20100913 (prerelease) (GCC)
configure:3263: $? = 0
configure:3270: x86_64-w64-mingw32-gcc -V >&5
x86_64-w64-mingw32-gcc.exe: '-V' option must have argument
configure:3274: $? = 1
configure:3297: checking for C compiler default output file name
configure:3319: x86_64-w64-mingw32-gcc    conftest.c  >&5
configure:3323: $? = 0
configure:3361: result: a.exe
configure:3380: checking whether the C compiler works
configure:3390: ./a.exe
./configure: line 3392: ./a.exe: Bad file number
configure:3394: $? = 126
configure:3413: result: yes
configure:3420: checking whether we are cross compiling
configure:3422: result: yes
configure:3425: checking for suffix of executables
configure:3432: x86_64-w64-mingw32-gcc -o conftest.exe    conftest.c  >&5
configure:3436: $? = 0
configure:3462: result: .exe
configure:3468: checking for suffix of object files
configure:3494: x86_64-w64-mingw32-gcc -c   conftest.c >&5
configure:3498: $? = 0
configure:3523: result: o
configure:3527: checking whether we are using the GNU C compiler
configure:3556: x86_64-w64-mingw32-gcc -c   conftest.c >&5
configure:3563: $? = 0
configure:3580: result: yes
configure:3589: checking whether x86_64-w64-mingw32-gcc accepts -g
configure:3619: x86_64-w64-mingw32-gcc -c -g  conftest.c >&5
configure:3626: $? = 0
configure:3727: result: yes
configure:3744: checking for x86_64-w64-mingw32-gcc option to accept ISO C89
configure:3818: x86_64-w64-mingw32-gcc  -c -g -O2  conftest.c >&5
configure:3825: $? = 0
configure:3848: result: none needed
configure:3894: x86_64-w64-mingw32-gcc -c -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:22:1: error: 'choke' undeclared (first use in this function)
conftest.c:22:1: note: each undeclared identifier is reported only
once for each function it appears in
conftest.c:22:7: error: expected ';' before 'me'
configure:3901: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "9.0.2"
| #define PACKAGE_STRING "PostgreSQL 9.0.2"
| #define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org"
| #define PG_VERSION "9.0.2"
| #define PG_MAJORVERSION "9.0"
| #define USE_INTEGER_DATETIMES 1
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR "5432"
| #define BLCKSZ 8192
| #define RELSEG_SIZE 131072
| #define XLOG_BLCKSZ 8192
| #define XLOG_SEG_SIZE (16 * 1024 * 1024)
| /* end confdefs.h.  */
|
| int
| main ()
| {
| #ifndef __INTEL_COMPILER
| choke me
| #endif
|   ;
|   return 0;
| }
configure:3941: x86_64-w64-mingw32-gcc -c -g -O2  conftest.c >&5
conftest.c: In function 'main':
conftest.c:22:1: error: 'choke' undeclared (first use in this function)
conftest.c:22:1: note: each undeclared identifier is reported only
once for each function it appears in
conftest.c:22:7: error: expected ';' before 'me'
configure:3948: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "9.0.2"
| #define PACKAGE_STRING "PostgreSQL 9.0.2"
| #define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org"
| #define PG_VERSION "9.0.2"
| #define PG_MAJORVERSION "9.0"
| #define USE_INTEGER_DATETIMES 1
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR "5432"
| #define BLCKSZ 8192
| #define RELSEG_SIZE 131072
| #define XLOG_BLCKSZ 8192
| #define XLOG_SEG_SIZE (16 * 1024 * 1024)
| /* end confdefs.h.  */
|
| int
| main ()
| {
| #ifndef __SUNPRO_C
| choke me
| #endif
|   ;
|   return 0;
| }
configure:4002: checking if x86_64-w64-mingw32-gcc supports
-Wdeclaration-after-statement
configure:4027: x86_64-w64-mingw32-gcc -c -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
conftest.c >&5
configure:4034: $? = 0
configure:4039: result: yes
configure:4052: checking if x86_64-w64-mingw32-gcc supports -Wendif-labels
configure:4077: x86_64-w64-mingw32-gcc -c -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels  conftest.c >&5
configure:4084: $? = 0
configure:4089: result: yes
configure:4103: checking if x86_64-w64-mingw32-gcc supports -fno-strict-aliasing
configure:4128: x86_64-w64-mingw32-gcc -c -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing  conftest.c >&5
configure:4135: $? = 0
configure:4140: result: yes
configure:4154: checking if x86_64-w64-mingw32-gcc supports -fwrapv
configure:4179: x86_64-w64-mingw32-gcc -c -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv  conftest.c >&5
configure:4186: $? = 0
configure:4191: result: yes
configure:4400: checking whether the C compiler still works
configure:4423: x86_64-w64-mingw32-gcc -o conftest.exe -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv
-I./src/include/port/win32 -DEXEC_BACKEND
-Wl,--allow-multiple-definition conftest.c  >&5
configure:4430: $? = 0
configure:4438: result: yes
configure:4480: x86_64-w64-mingw32-gcc -c -O2 -Wall
-Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Wendif-labels -fno-strict-aliasing -fwrapv
-I./src/include/port/win32 -DEXEC_BACKEND conftest.c >&5
configure:4487: $? = 0
configure:4510: checking how to run the C preprocessor
configure:4550: x86_64-w64-mingw32-gcc -E  -I./src/include/port/win32
-DEXEC_BACKEND conftest.c
configure:4557: $? = 0
configure:4588: x86_64-w64-mingw32-gcc -E  -I./src/include/port/win32
-DEXEC_BACKEND conftest.c
conftest.c:17:28: fatal error: ac_nonexistent.h: No such file or directory
compilation terminated.
configure:4595: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "9.0.2"
| #define PACKAGE_STRING "PostgreSQL 9.0.2"
| #define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org"
| #define PG_VERSION "9.0.2"
| #define PG_MAJORVERSION "9.0"
| #define USE_INTEGER_DATETIMES 1
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR "5432"
| #define BLCKSZ 8192
| #define RELSEG_SIZE 131072
| #define XLOG_BLCKSZ 8192
| #define XLOG_SEG_SIZE (16 * 1024 * 1024)
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:4628: result: x86_64-w64-mingw32-gcc -E
configure:4657: x86_64-w64-mingw32-gcc -E  -I./src/include/port/win32
-DEXEC_BACKEND conftest.c
configure:4664: $? = 0
configure:4695: x86_64-w64-mingw32-gcc -E  -I./src/include/port/win32
-DEXEC_BACKEND conftest.c
conftest.c:17:28: fatal error: ac_nonexistent.h: No such file or directory
compilation terminated.
configure:4702: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME "PostgreSQL"
| #define PACKAGE_TARNAME "postgresql"
| #define PACKAGE_VERSION "9.0.2"
| #define PACKAGE_STRING "PostgreSQL 9.0.2"
| #define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org"
| #define PG_VERSION "9.0.2"
| #define PG_MAJORVERSION "9.0"
| #define USE_INTEGER_DATETIMES 1
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR "5432"
| #define BLCKSZ 8192
| #define RELSEG_SIZE 131072
| #define XLOG_BLCKSZ 8192
| #define XLOG_SEG_SIZE (16 * 1024 * 1024)
| /* end confdefs.h.  */
| #include <ac_nonexistent.h>
configure:4861: checking allow thread-safe client libraries
configure:4895: result: yes
configure:4902: checking whether to build with Tcl
configure:4930: result: no
configure:4966: checking whether to build Perl modules
configure:4994: result: no
configure:5001: checking whether to build Python modules
configure:5029: result: no
configure:5036: checking whether to build with GSSAPI support
configure:5071: result: no
configure:5078: checking whether to build with Kerberos 5 support
configure:5113: result: no
configure:5161: checking whether to build with PAM support
configure:5193: result: no
configure:5201: checking whether to build with LDAP support
configure:5233: result: no
configure:5241: checking whether to build with Bonjour support
configure:5273: result: no
configure:5281: checking whether to build with OpenSSL support
configure:5313: result: no
configure:5352: WARNING: *** Readline does not work on MinGW --- disabling
configure:5625: checking for grep that handles long lines and -e
configure:5685: result: /bin/grep
configure:5690: checking for egrep
configure:5754: result: /bin/grep -E
configure:5805: checking for ld used by GCC
configure:5868: result:
d:/amber/devtool/mingw64-1.0-20100913/x86_64-w64-mingw32/bin/ld.exe
configure:5877: checking if the linker
(d:/amber/devtool/mingw64-1.0-20100913/x86_64-w64-mingw32/bin/ld.exe)
is GNU ld
GNU ld (GNU Binutils) 2.20.51.20100913
configure:5889: result: yes
configure:5962: checking for x86_64-w64-mingw32-ranlib
configure:5978: found /mingw/bin/x86_64-w64-mingw32-ranlib
configure:5989: result: x86_64-w64-mingw32-ranlib
configure:6055: checking for x86_64-w64-mingw32-strip
configure:6071: found /mingw/bin/x86_64-w64-mingw32-strip
configure:6082: result: x86_64-w64-mingw32-strip
configure:6145: checking whether it is possible to strip libraries
configure:6150: result: yes
configure:6164: checking for x86_64-w64-mingw32-ar
configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar
configure:6191: result: x86_64-w64-mingw32-ar
configure:6257: checking for x86_64-w64-mingw32-dlltool
configure:6273: found /mingw/bin/x86_64-w64-mingw32-dlltool
configure:6284: result: x86_64-w64-mingw32-dlltool
configure:6349: checking for x86_64-w64-mingw32-dllwrap
configure:6365: found /mingw/bin/x86_64-w64-mingw32-dllwrap
configure:6376: result: x86_64-w64-mingw32-dllwrap
configure:6441: checking for x86_64-w64-mingw32-windres
configure:6457: found /mingw/bin/x86_64-w64-mingw32-windres
configure:6468: result: x86_64-w64-mingw32-windres
configure:6534: checking for tar
configure:6552: found /bin/tar
configure:6564: result: /bin/tar
configure:6572: checking whether ln -s works
configure:6579: result: no, using cp -p
configure:6587: checking for gawk
configure:6603: found /bin/gawk
configure:6614: result: gawk
configure:6625: checking for a thread-safe mkdir -p
configure:6664: result: /bin/mkdir -p
configure:6680: checking for bison
configure:6698: found /bin/bison
configure:6710: result: /bin/bison
configure:6725: using bison (GNU Bison) 2.4.2
configure:6756: checking for flex
configure:6801: result: /bin/flex
configure:6821: using flex 2.5.35
configure:6833: checking for perl
configure:6851: found /bin/perl
configure:6863: result: /bin/perl
configure:6875: using perl 5.6.1
configure:6882: WARNING:
*** The installed version of Perl, /bin/perl, is too old to use with PostgreSQL.
*** Perl version 5.8 or later is required, but this is 5.6.1.
configure:6895: WARNING:
*** Without Perl you will not be able to build PostgreSQL from Git.
*** You can obtain Perl from any CPAN mirror site.
*** (If you are using the official distribution of PostgreSQL then you do not
*** need to worry about this, because the Perl output is pre-generated.)
configure:7071: checking for zic
configure:7104: result: no
configure:7113: error:
When cross-compiling, either use the option --with-system-tzdata to use
existing time-zone data, or set the environment variable ZIC to a zic
program to use during the build.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-pc-mingw32
ac_cv_c_compiler_gnu=yes
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_DOCBOOKSTYLE_set=
ac_cv_env_DOCBOOKSTYLE_value=
ac_cv_env_LDFLAGS_EX_set=
ac_cv_env_LDFLAGS_EX_value=
ac_cv_env_LDFLAGS_SL_set=
ac_cv_env_LDFLAGS_SL_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=x86_64-w64-mingw32
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_exeext=.exe
ac_cv_host=x86_64-w64-mingw32
ac_cv_objext=o
ac_cv_path_BISON=/bin/bison
ac_cv_path_EGREP='/bin/grep -E'
ac_cv_path_GREP=/bin/grep
ac_cv_path_LD=d:/amber/devtool/mingw64-1.0-20100913/x86_64-w64-mingw32/bin/ld.exe
ac_cv_path_PERL=/bin/perl
ac_cv_path_TAR=/bin/tar
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AR=x86_64-w64-mingw32-ar
ac_cv_prog_AWK=gawk
ac_cv_prog_CC=x86_64-w64-mingw32-gcc
ac_cv_prog_CPP='x86_64-w64-mingw32-gcc -E'
ac_cv_prog_DLLTOOL=x86_64-w64-mingw32-dlltool
ac_cv_prog_DLLWRAP=x86_64-w64-mingw32-dllwrap
ac_cv_prog_RANLIB=x86_64-w64-mingw32-ranlib
ac_cv_prog_STRIP=x86_64-w64-mingw32-strip
ac_cv_prog_WINDRES=x86_64-w64-mingw32-windres
ac_cv_prog_cc_c89=
ac_cv_prog_cc_g=yes
ac_cv_prog_gnu_ld=yes
pgac_cv_path_flex=/bin/flex

## ----------------- ##
## Output variables. ##
## ----------------- ##

AR='x86_64-w64-mingw32-ar'
AWK='gawk'
BISON='/bin/bison'
BISONFLAGS=''
CC='x86_64-w64-mingw32-gcc'
CFLAGS='-O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
-fwrapv'
COLLATEINDEX=''
CPP='x86_64-w64-mingw32-gcc -E'
CPPFLAGS=' -I./src/include/port/win32 -DEXEC_BACKEND '
DEFS=''
DLLTOOL='x86_64-w64-mingw32-dlltool'
DLLWRAP='x86_64-w64-mingw32-dllwrap'
DOCBOOKSTYLE=''
DTRACE=''
DTRACEFLAGS=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP='/bin/grep -E'
ELF_SYS=''
EXEEXT='.exe'
FLEX='/bin/flex'
FLEXFLAGS=''
GCC='yes'
GCOV=''
GENHTML=''
GREP='/bin/grep'
HAVE_IPV6=''
HAVE_POSIX_SIGNALS=''
INCLUDES=''
JADE=''
LCOV=''
LD='d:/amber/devtool/mingw64-1.0-20100913/x86_64-w64-mingw32/bin/ld.exe'
LDAP_LIBS_BE=''
LDAP_LIBS_FE=''
LDFLAGS='-Wl,--allow-multiple-definition '
LDFLAGS_EX=''
LDFLAGS_SL=''
LIBOBJS=''
LIBS=''
LN_S='cp -p'
LTLIBOBJS=''
MKDIR_P='/bin/mkdir -p'
MSGFMT=''
MSGMERGE=''
NSGMLS=''
OBJEXT='o'
OSSP_UUID_LIBS=''
OSX=''
PACKAGE_BUGREPORT='pgsql-bugs@postgresql.org'
PACKAGE_NAME='PostgreSQL'
PACKAGE_STRING='PostgreSQL 9.0.2'
PACKAGE_TARNAME='postgresql'
PACKAGE_VERSION='9.0.2'
PATH_SEPARATOR=':'
PERL=''
PG_MAJORVERSION='9.0'
PORTNAME='win32'
PTHREAD_CC=''
PTHREAD_CFLAGS=''
PTHREAD_LIBS=''
PYTHON=''
RANLIB='x86_64-w64-mingw32-ranlib'
SHELL='/bin/sh'
STRIP='x86_64-w64-mingw32-strip'
STRIP_SHARED_LIB='x86_64-w64-mingw32-strip --strip-unneeded'
STRIP_STATIC_LIB='x86_64-w64-mingw32-strip -x'
SUN_STUDIO_CC='no'
TAR='/bin/tar'
TAS=''
TCLSH=''
TCL_CONFIG_SH=''
TCL_INCLUDE_SPEC=''
TCL_LIBS=''
TCL_LIB_FILE=''
TCL_LIB_SPEC=''
TCL_SHARED_BUILD=''
TCL_SHLIB_LD_LIBS=''
WANTED_LANGUAGES=''
WINDRES='x86_64-w64-mingw32-windres'
XGETTEXT=''
XML2_CONFIG=''
XSLTPROC=''
ZIC=''
ac_ct_CC=''
acx_pthread_config=''
autodepend=''
bindir='${exec_prefix}/bin'
build='i686-pc-mingw32'
build_alias=''
build_cpu='i686'
build_os='mingw32'
build_vendor='pc'
configure_args=' '\''--without-zlib'\''
'\''--host=x86_64-w64-mingw32'\'' '\''--prefix=D:/psqlbin'\''
'\''host_alias=x86_64-w64-mingw32'\'''
datadir='${datarootdir}'
datarootdir='${prefix}/share'
default_port='5432'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
dvidir='${docdir}'
enable_coverage='no'
enable_debug='no'
enable_dtrace='no'
enable_nls='no'
enable_profiling='no'
enable_rpath='yes'
enable_shared='yes'
enable_thread_safety='yes'
exec_prefix='NONE'
have_docbook=''
host='x86_64-w64-mingw32'
host_alias='x86_64-w64-mingw32'
host_cpu='x86_64'
host_os='mingw32'
host_vendor='w64'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
krb_srvtab=''
ld_R_works=''
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
perl_archlibexp=''
perl_embed_ldflags=''
perl_privlibexp=''
perl_useshrplib=''
prefix='D:/psqlbin'
program_transform_name='s,x,x,'
psdir='${docdir}'
python_additional_libs=''
python_configdir=''
python_includespec=''
python_libdir=''
python_libspec=''
python_majorversion=''
python_version=''
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
target_alias=''
vpath_build=''
with_bonjour='no'
with_gnu_ld='yes'
with_gssapi='no'
with_krb5='no'
with_ldap='no'
with_libxml='no'
with_libxslt='no'
with_openssl='no'
with_ossp_uuid='no'
with_pam='no'
with_perl='no'
with_python='no'
with_system_tzdata=''
with_tcl='no'
with_zlib='no'

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME "PostgreSQL"
#define PACKAGE_TARNAME "postgresql"
#define PACKAGE_VERSION "9.0.2"
#define PACKAGE_STRING "PostgreSQL 9.0.2"
#define PACKAGE_BUGREPORT "pgsql-bugs@postgresql.org"
#define PG_VERSION "9.0.2"
#define PG_MAJORVERSION "9.0"
#define USE_INTEGER_DATETIMES 1
#define DEF_PGPORT 5432
#define DEF_PGPORT_STR "5432"
#define BLCKSZ 8192
#define RELSEG_SIZE 131072
#define XLOG_BLCKSZ 8192
#define XLOG_SEG_SIZE (16 * 1024 * 1024)
#define ENABLE_THREAD_SAFETY 1
#define PG_KRB_SRVNAM "postgres"

configure: exit 1

  7. Re: mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-01-28T10:19:15Z

    
On 01/27/2011 10:51 PM, Xiaobo Gu wrote:
> On Fri, Jan 28, 2011 at 11:44 AM, Andrew Dunstan<andrew@dunslane.net>  wrote:
>> >
>> >
>> >  On 01/27/2011 10:37 PM, Xiaobo Gu wrote:
>>> >>
>>> >>  --with-system-tzdata=/usr/share/zoneinfo
>> >
>> >  Why on earth are you doing this on Windows? That's crazy. Did you run "make
>> >  check"? You should always do that after a build before you install.
>> >
> configure does not pass if I omit --with-system-tzdata=/usr/share/zoneinfo
>
> Content of  config.log
>

You need to listen to the things that are said to you more. Someone ele 
already asked you not to post long config.log files in the body of your 
emails. All you needed to paste was these lines:


> configure:7071: checking for zic
> configure:7104: result: no
> configure:7113: error:
> When cross-compiling, either use the option --with-system-tzdata to use
> existing time-zone data, or set the environment variable ZIC to a zic
> program to use during the build.

Why are you cross-compiling? I built without any need to do that. Change 
the names of the binaries on the m mingw64/bin directory to remove the 
platform prefix, put that directory at the head of your PATH, and run a 
plain configure. Works like a charm.

You should probably wait a little while (i.e a week or so) for me to 
work out the wrinkles in this. Then I will publish some instructions on 
the wiki.

cheers

andre

  8. Re: mingw64

    JonY <jon_y@users.sourceforge.net> — 2011-01-28T13:09:40Z

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/2011 18:19, Andrew Dunstan wrote:
>> configure:7071: checking for zic
>> configure:7104: result: no
>> configure:7113: error:
>> When cross-compiling, either use the option --with-system-tzdata to use
>> existing time-zone data, or set the environment variable ZIC to a zic
>> program to use during the build.
> 
> Why are you cross-compiling? I built without any need to do that. Change
> the names of the binaries on the m mingw64/bin directory to remove the
> platform prefix, put that directory at the head of your PATH, and run a
> plain configure. Works like a charm.
> 
> You should probably wait a little while (i.e a week or so) for me to
> work out the wrinkles in this. Then I will publish some instructions on
> the wiki.

Hi,

the mingw64 toolchain is usually built as a cross compiler, so its not
his fault there, its not supposed to be renamed. Will it be possible to
check first if the host machine actually allows using tzdata related
stuff before erroring out?

Disclaimer: I don't know anything about tzdata or zic other than its for
timezone information.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk1CwBQACgkQp56AKe10wHf3ZwCaAyaBELQyVXcwD7LxLDiatOZy
YUUAnRZw0d61YNXlwdF0pzdlUGkLArFM
=90yM
-----END PGP SIGNATURE-----

  9. Re: mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-01-28T15:23:01Z

    
On 01/28/2011 08:09 AM, JonY wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 1/28/2011 18:19, Andrew Dunstan wrote:
>>> configure:7071: checking for zic
>>> configure:7104: result: no
>>> configure:7113: error:
>>> When cross-compiling, either use the option --with-system-tzdata to use
>>> existing time-zone data, or set the environment variable ZIC to a zic
>>> program to use during the build.
>> Why are you cross-compiling? I built without any need to do that. Change
>> the names of the binaries on the m mingw64/bin directory to remove the
>> platform prefix, put that directory at the head of your PATH, and run a
>> plain configure. Works like a charm.
>>
>> You should probably wait a little while (i.e a week or so) for me to
>> work out the wrinkles in this. Then I will publish some instructions on
>> the wiki.
> Hi,
>
> the mingw64 toolchain is usually built as a cross compiler, so its not
> his fault there, its not supposed to be renamed. Will it be possible to
> check first if the host machine actually allows using tzdata related
> stuff before erroring out?
>
> Disclaimer: I don't know anything about tzdata or zic other than its for
> timezone information.
>
>


Maybe that's true. But Windows doesn't come wth zic nor a timezone 
database like Unix usually has. Part of the reason we started 
maintaining our own timezone sets was that we needed it on Windows. And 
since we do mke rovision for that, jumping through these hoops seems 
silly. I'm much more interested in building 64 bit Postgres for Windows 
natively than as a cross compilation, and as I reported yesterday, it's 
entirely possible. The cross-compilaion without renaming failed 
miserably on my setuo, because, for example, configure used the wrong ar.

If you want to cross-compile on Windows, then the best solution seems to 
be to build the native zic in the Postgres source, stash it away 
somewhere, and then use that in your cross compilation.  Ugh.

cheers

andrew

  10. Re: mingw64

    JonY <jon_y@users.sourceforge.net> — 2011-01-28T15:37:19Z

    -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/28/2011 23:23, Andrew Dunstan wrote:
> 
> 
> On 01/28/2011 08:09 AM, JonY wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 1/28/2011 18:19, Andrew Dunstan wrote:
>>>> configure:7071: checking for zic
>>>> configure:7104: result: no
>>>> configure:7113: error:
>>>> When cross-compiling, either use the option --with-system-tzdata to use
>>>> existing time-zone data, or set the environment variable ZIC to a zic
>>>> program to use during the build.
>>> Why are you cross-compiling? I built without any need to do that. Change
>>> the names of the binaries on the m mingw64/bin directory to remove the
>>> platform prefix, put that directory at the head of your PATH, and run a
>>> plain configure. Works like a charm.
>>>
>>> You should probably wait a little while (i.e a week or so) for me to
>>> work out the wrinkles in this. Then I will publish some instructions on
>>> the wiki.
>> Hi,
>>
>> the mingw64 toolchain is usually built as a cross compiler, so its not
>> his fault there, its not supposed to be renamed. Will it be possible to
>> check first if the host machine actually allows using tzdata related
>> stuff before erroring out?
>>
>> Disclaimer: I don't know anything about tzdata or zic other than its for
>> timezone information.
>>
>>
> 
> 
> Maybe that's true. But Windows doesn't come wth zic nor a timezone
> database like Unix usually has. Part of the reason we started
> maintaining our own timezone sets was that we needed it on Windows. And
> since we do mke rovision for that, jumping through these hoops seems
> silly. I'm much more interested in building 64 bit Postgres for Windows
> natively than as a cross compilation, and as I reported yesterday, it's
> entirely possible. The cross-compilaion without renaming failed
> miserably on my setuo, because, for example, configure used the wrong ar.
> 

*** Moving thread to mingw-w64-public ***

There is/was a bug in autotools, where the wrong AR was used, try adding
"AC_CHECK_TOOL([AR], [ar], [:])" as a workaround.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk1C4q8ACgkQp56AKe10wHf6TACfcjDm26JbFkpT3mPa+ZTPqTGS
CUUAn2Z7bc6HUX3dAQOg0YACUORlR7Ih
=CXcC
-----END PGP SIGNATURE-----

  11. Re: mingw64

    Xiaobo Gu <guxiaobo1982@gmail.com> — 2011-01-29T08:58:47Z

    >
> Why are you cross-compiling? I built without any need to do that. Change the
> names of the binaries on the m mingw64/bin directory to remove the platform
> prefix, put that directory at the head of your PATH, and run a plain
> configure. Works like a charm.
I have two work computers, one is 32 bit Windows XP SP3, the other  is
64 bit Windows 7 Home basic, one is at home, the other is at work, so
to keep the same environment is more convenient for me.

I have successfully built PostgreSQL 9.0.2 according to your
suggestion on 64bit Win7 (but using an administrator user), and the
corresponding RPostgreSQL package works now, thank you all that have
helped.

Xiaobo Gu

  12. Re: [Mingw-users] mingw64

    Peter Rosin <peda@lysator.liu.se> — 2011-01-29T13:26:24Z

    >> Maybe that's true. But Windows doesn't come wth zic nor a timezone
>> database like Unix usually has. Part of the reason we started
>> maintaining our own timezone sets was that we needed it on Windows. And
>> since we do mke rovision for that, jumping through these hoops seems
>> silly. I'm much more interested in building 64 bit Postgres for Windows
>> natively than as a cross compilation, and as I reported yesterday, it's
>> entirely possible. The cross-compilaion without renaming failed
>> miserably on my setuo, because, for example, configure used the wrong ar.
>>
> 
> *** Moving thread to mingw-w64-public ***
> 
> There is/was a bug in autotools, where the wrong AR was used, try adding
> "AC_CHECK_TOOL([AR], [ar], [:])" as a workaround.

Hi,

I am probably missing something, but from a message posted previously
in this thread [1] I find this:

>Invocation command line was
>
>  $ ./configure --without-zlib --host=x86_64-w64-mingw32 --prefix=D:/psqlbin

And the following snippets in config.log:

>configure:6164: checking for x86_64-w64-mingw32-ar
>configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar
>configure:6191: result: x86_64-w64-mingw32-ar

this when listing cache variables:

>ac_cv_prog_AR=x86_64-w64-mingw32-ar

and this when listing output variables:

>AR='x86_64-w64-mingw32-ar'

Exactly how is x86_64-w64-mingw32-ar the wrong ar?
Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?

Cheers,
Peter

[1] http://permalink.gmane.org/gmane.comp.db.postgresql.devel.general/159184

  13. Re: [Mingw-users] mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-01-29T22:03:42Z

    
On 01/29/2011 08:26 AM, Peter Rosin wrote:
>>> Maybe that's true. But Windows doesn't come wth zic nor a timezone
>>> database like Unix usually has. Part of the reason we started
>>> maintaining our own timezone sets was that we needed it on Windows. And
>>> since we do mke rovision for that, jumping through these hoops seems
>>> silly. I'm much more interested in building 64 bit Postgres for Windows
>>> natively than as a cross compilation, and as I reported yesterday, it's
>>> entirely possible. The cross-compilaion without renaming failed
>>> miserably on my setuo, because, for example, configure used the wrong ar.
>>>
>> *** Moving thread to mingw-w64-public ***
>>
>> There is/was a bug in autotools, where the wrong AR was used, try adding
>> "AC_CHECK_TOOL([AR], [ar], [:])" as a workaround.
> Hi,
>
> I am probably missing something, but from a message posted previously
> in this thread [1] I find this:
>
>> Invocation command line was
>>
>>   $ ./configure --without-zlib --host=x86_64-w64-mingw32 --prefix=D:/psqlbin
>

Yeah, this is working for me now. I don't know what went wrong previously.

Thanks for following up.

But the point remains that using --with-system-tzdata is silly on 
Windows. If you're cross-compiling (e.g. building 64bit Postgres on 
32bit Windows), your best bet is probably to build natively and use the 
zic.exe from the native build.  If you're only bulding to get the client 
libraries I guess it doesn't matter, but otherwise it sure does.

cheers
'
andrew

  14. Re: [Mingw-users] mingw64

    Ralf Wildenhues <ralf.wildenhues@gmx.de> — 2011-02-12T10:10:31Z

    Hello, and sorry for the delay,

* Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?

Automake outputs 'AR = ar' in Makefile.in for rules creating old
libraries iff neither AC_PROG_LIBTOOL nor another method to define
AR correctly is used in configure.ac.

So this issue concerns packages using Automake but not using Libtool.

I figured with AM_PROG_AR eventually being needed anyway that would fix
this in one go ...

A good workaround, as already mentioned, is to use this in configure.ac:
  AC_CHECK_TOOL([AR], [ar], [false])

Cheers,
Ralf

  15. Re: [Mingw-users] mingw64

    Andrew Dunstan <andrew@dunslane.net> — 2011-02-14T00:06:27Z

    
On 02/12/2011 05:10 AM, Ralf Wildenhues wrote:
> Hello, and sorry for the delay,
>
> * Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
>> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?
> Automake outputs 'AR = ar' in Makefile.in for rules creating old
> libraries iff neither AC_PROG_LIBTOOL nor another method to define
> AR correctly is used in configure.ac.
>
> So this issue concerns packages using Automake but not using Libtool.
>
> I figured with AM_PROG_AR eventually being needed anyway that would fix
> this in one go ...
>
> A good workaround, as already mentioned, is to use this in configure.ac:
>    AC_CHECK_TOOL([AR], [ar], [false])
>

This was sorted out some time ago.

cheers

andrew

  16. Re: mingw64

    Peter Rosin <peda@lysator.liu.se> — 2011-02-14T08:14:03Z

    Den 2011-02-12 11:10 skrev Ralf Wildenhues:
> Hello, and sorry for the delay,
> 
> * Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
>> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?
> 
> Automake outputs 'AR = ar' in Makefile.in for rules creating old
> libraries iff neither AC_PROG_LIBTOOL nor another method to define
> AR correctly is used in configure.ac.
> 
> So this issue concerns packages using Automake but not using Libtool.
> 
> I figured with AM_PROG_AR eventually being needed anyway that would fix
> this in one go ...
> 
> A good workaround, as already mentioned, is to use this in configure.ac:
>   AC_CHECK_TOOL([AR], [ar], [false])

I just cannot understand why the workaround isn't always working in
this case.

There was a log posted with this in it
(in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02697.php):

...
configure:5962: checking for x86_64-w64-mingw32-ranlib
configure:5978: found /mingw/bin/x86_64-w64-mingw32-ranlib
configure:5989: result: x86_64-w64-mingw32-ranlib
configure:6055: checking for x86_64-w64-mingw32-strip
configure:6071: found /mingw/bin/x86_64-w64-mingw32-strip
configure:6082: result: x86_64-w64-mingw32-strip
configure:6145: checking whether it is possible to strip libraries
configure:6150: result: yes
configure:6164: checking for x86_64-w64-mingw32-ar
configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar
configure:6191: result: x86_64-w64-mingw32-ar
configure:6257: checking for x86_64-w64-mingw32-dlltool
configure:6273: found /mingw/bin/x86_64-w64-mingw32-dlltool
configure:6284: result: x86_64-w64-mingw32-dlltool
configure:6349: checking for x86_64-w64-mingw32-dllwrap
configure:6365: found /mingw/bin/x86_64-w64-mingw32-dllwrap
configure:6376: result: x86_64-w64-mingw32-dllwrap
configure:6441: checking for x86_64-w64-mingw32-windres
configure:6457: found /mingw/bin/x86_64-w64-mingw32-windres
configure:6468: result: x86_64-w64-mingw32-windres
...

Which seem to match this snippet from configure.in:

...
AC_PROG_RANLIB
PGAC_CHECK_STRIP
AC_CHECK_TOOL(AR, ar, ar)
if test "$PORTNAME" = "win32"; then
  AC_CHECK_TOOL(DLLTOOL, dlltool, dlltool)
  AC_CHECK_TOOL(DLLWRAP, dllwrap, dllwrap)
  AC_CHECK_TOOL(WINDRES, windres, windres)
fi
...

Sure, AC_CHECK_TOOL has under-quoted arguments and the last argument is
'ar' instead of 'false'.  But that shouldn't really matter here.  (Or
does it?)

Still, elsewhere in the thread there's a report about the wrong ar being
used.
(in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02713.php)

Sure, the configure log and the "wrong ar"-report are not from the same
person, but the configure script should be the same for everybody (git
log hints that this part of configure has been stable for a couple of
years).

It just doesn't add up.

Cheers,
Peter

  17. Re: [Mingw-users] mingw64

    Ralf Wildenhues <ralf.wildenhues@gmx.de> — 2011-02-16T06:14:17Z

    Hi Peter,

* Peter Rosin wrote on Mon, Feb 14, 2011 at 09:14:03AM CET:
> Den 2011-02-12 11:10 skrev Ralf Wildenhues:
> > * Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
> >> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?
> > 
> > Automake outputs 'AR = ar' in Makefile.in for rules creating old
> > libraries iff neither AC_PROG_LIBTOOL nor another method to define
> > AR correctly is used in configure.ac.

> > A good workaround, as already mentioned, is to use this in configure.ac:
> >   AC_CHECK_TOOL([AR], [ar], [false])
> 
> I just cannot understand why the workaround isn't always working in
> this case.
> 
> There was a log posted with this in it
> (in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02697.php):

[...]
> configure:6164: checking for x86_64-w64-mingw32-ar
> configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar
> configure:6191: result: x86_64-w64-mingw32-ar
[...]

> Which seem to match this snippet from configure.in:
> 
> ...
> AC_PROG_RANLIB
> PGAC_CHECK_STRIP
> AC_CHECK_TOOL(AR, ar, ar)
> if test "$PORTNAME" = "win32"; then
>   AC_CHECK_TOOL(DLLTOOL, dlltool, dlltool)
>   AC_CHECK_TOOL(DLLWRAP, dllwrap, dllwrap)
>   AC_CHECK_TOOL(WINDRES, windres, windres)
> fi
> ...
> 
> Sure, AC_CHECK_TOOL has under-quoted arguments and the last argument is
> 'ar' instead of 'false'.  But that shouldn't really matter here.  (Or
> does it?)

No, that's irrelevant.

> Still, elsewhere in the thread there's a report about the wrong ar being
> used.
> (in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02713.php)

Well, the poster wrote that it worked now though:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg02806.php

> Sure, the configure log and the "wrong ar"-report are not from the same
> person, but the configure script should be the same for everybody (git
> log hints that this part of configure has been stable for a couple of
> years).
> 
> It just doesn't add up.

FWIW, I don't see enough evidence of breakage to be able to analyze it.

Thanks,
Ralf