>> 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