Re: [HACKERS] [Mingw-users] mingw64
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Mingw-users] mingw64
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Mingw-users] mingw64
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Mingw-users] mingw64
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [Mingw-users] mingw64
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
