Re: [HACKERS] mingw64
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 -- 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] mingw64
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 -- 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] mingw64
On 01/27/2011 10:51 PM, Xiaobo Gu wrote: On Fri, Jan 28, 2011 at 11:44 AM, Andrew Dunstanand...@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 -- 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] mingw64
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 -- 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] mingw64
-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- 0xED74C077.asc Description: application/pgp-keys -- 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] mingw64
-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- -- 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] mingw64
On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan and...@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 -- 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] mingw64
On 01/27/2011 08:23 PM, Xiaobo Gu wrote: On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstanand...@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 -- 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] mingw64
On Fri, Jan 28, 2011 at 8:12 AM, Andrew Dunstan and...@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 -- 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] mingw64
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 -- 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] mingw64
On Fri, Jan 28, 2011 at 11:44 AM, Andrew Dunstan and...@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-gccconftest.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.execonftest.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
