From: Peter R. <pe...@ly...> - 2011-01-29 13:26:35
|
>> 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 |