Re: [HACKERS] mingw64

2011-01-29 Thread Xiaobo Gu 

 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

[HACKERS] Do you have a plan to support Simplified Chinese Locale

2011-01-29 Thread Xiaobo Gu 
Hi,
Or can you give some instructions about how to do this, 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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-27 Thread Xiaobo Gu 
Hi,
 I have a talk with MinGW developer, because I am not so familiar with
the UNIX configure and build system, can you help to resolve the
problem please.



jon_y: XiaoboGu: try actually reading config.log
20:18 jon_y: look for winsock2.h in it
20:18 jon_y: you should find it, along with the error nearby
20:19 tjtag: thats fixed it, will do that also ktietz
20:20 XiaoboGu:
d:/amber/devtool/mingw64-1.0-20100913/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:1035:37:
note: previous declaration of 'accept' was here
20:21 jon_y: like I said, the accept() probe doesn't work due to
difference in expectation
20:23 tjtag: brb
20:23 XiaoboGu: the path is OK
20:24 XiaoboGu: I really can't understand this
20:24 jon_y: its probing accept() for known implementations
20:24 XiaoboGu: do you mean the configure script has a problem
20:25 jon_y: none of them match the one in winsock2.h
20:25 jon_y: I don't know, it could be mingw-w64's fault too
20:25 jon_y: please contact psql and ask for a list of accept()
implementations checked


On Tue, Jan 25, 2011 at 10:54 PM, Andrew Dunstan and...@dunslane.net wrote:


 On 01/25/2011 09:15 AM, Xiaobo Gu wrote:

 Hi Andrew,
 The config.log is as following


 So what is the declaration of accept at

 d:/amber/devtool/rtools/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:1035:37:

 ?

 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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-27 Thread Xiaobo Gu 
On Thu, Jan 27, 2011 at 9:14 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote:
 On Thu, Jan 27, 2011 at 8:56 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote:
 On Thu, Jan 27, 2011 at 8:51 PM, Andrew Dunstan and...@dunslane.net wrote:


 On 01/27/2011 07:41 AM, Xiaobo Gu wrote:

 On Thu, Jan 27, 2011 at 8:37 PM, Andrew Dunstanand...@dunslane.net
  wrote:

 On 01/27/2011 07:31 AM, Xiaobo Gu wrote:

 Hi,
  I have a talk with MinGW developer, because I am not so familiar with
 the UNIX configure and build system, can you help to resolve the
 problem please.



 jon_y: XiaoboGu: try actually reading config.log
 20:18jon_y: look for winsock2.h in it
 20:18jon_y: you should find it, along with the error nearby
 20:19tjtag: thats fixed it, will do that also ktietz
 20:20XiaoboGu:


 d:/amber/devtool/mingw64-1.0-20100913/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:1035:37:
 note: previous declaration of 'accept' was here
 20:21jon_y: like I said, the accept() probe doesn't work due to
 difference in expectation
 20:23tjtag: brb
 20:23XiaoboGu: the path is OK
 20:24XiaoboGu: I really can't understand this
 20:24jon_y: its probing accept() for known implementations
 20:24XiaoboGu: do you mean the configure script has a problem
 20:25jon_y: none of them match the one in winsock2.h
 20:25jon_y: I don't know, it could be mingw-w64's fault too
 20:25jon_y: please contact psql and ask for a list of accept()
 implementations checked



 I am going to ignore your requests until you stop top-answering.

 I am sorry, do you mean there are problems when dealing with the socke
 function accept ?


 Clearly there is a problem, or configure would have worked. You need to
 answer the question I asked previously, namely what is the declaration of
 accept() in the mingw64 headers? You have that source and I don't so I can't
 answer the question.

 #ifndef __WINSOCK_WS1_SHARED
 /* these 46 functions have the same prototypes as in winsock2 */
  WINSOCK_API_LINKAGE SOCKET WSAAPI accept(SOCKET s,struct sockaddr
 *addr,int *addrlen);
  WINSOCK_API_LINKAGE int WSAAPI bind(SOCKET s,const struct sockaddr
 *name,int namelen);
  WINSOCK_API_LINKAGE int WSAAPI closesocket(SOCKET s);
  WINSOCK_API_LINKAGE int WSAAPI connect(SOCKET s,const struct
 sockaddr *name,int namelen);

 And these are type defines for SOCKET and struct sockaddr


 #ifndef ___WSA_SOCKET_TYPES_H
 #define ___WSA_SOCKET_TYPES_H

 #if 0
 typedef UINT_PTR        SOCKET;
 #else
 typedef INT_PTR         SOCKET;
 #endif

 #define INVALID_SOCKET  (SOCKET)(~0)
 #define SOCKET_ERROR    (-1)

 #endif /* ___WSA_SOCKET_TYPES_H */


 struct sockaddr {
        u_short sa_family;
        char    sa_data[14];
 };



And the definitions  for u_short and UINT_PTR INT_PTR are in :

_bsd_types.h

typedef unsigned short  u_short;


basetsd.h


#ifndef _W64
#define _W64
#endif

#ifdef _WIN64
  __MINGW_EXTENSION typedef __int64 INT_PTR,*PINT_PTR;
  __MINGW_EXTENSION typedef unsigned __int64 UINT_PTR,*PUINT_PTR;
  __MINGW_EXTENSION typedef __int64 LONG_PTR,*PLONG_PTR;
  __MINGW_EXTENSION typedef unsigned __int64 ULONG_PTR,*PULONG_PTR;
#define __int3264 __int64
#else
  typedef int INT_PTR,*PINT_PTR;
  typedef unsigned int UINT_PTR,*PUINT_PTR;
  typedef long LONG_PTR,*PLONG_PTR;
  typedef unsigned long ULONG_PTR,*PULONG_PTR;
#define __int3264 __int32
#endif

 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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-27 Thread Xiaobo Gu 
On Thu, Jan 27, 2011 at 10:01 PM, Andrew Dunstan and...@dunslane.net wrote:


 On 01/27/2011 08:51 AM, Robert Haas wrote:

 On Thu, Jan 27, 2011 at 7:31 AM, Xiaobo Guguxiaobo1...@gmail.com  wrote:

 20:25jon_y: please contact psql and ask for a list of accept()
 implementations checked

 It looks like we check each argument and the return type for a couple
 of possibilities:

 argument 1 can be int or unsigned int
 argument 2 can be struct sockaddr * or const struct sockaddr * or void *
 argument 3 can be int * or size_t * or socklen_t * or unsigned int * or
 void *
 the return type can be int or unsigned int PASCAL



 Yeah. it looks like the return type is the likely culprit. It looks like it
 wants either a signed or unsigned int64. Also, the mingw64 API uses the
 WSAAPI qualifier instead of PASCAL.


I am still trying, but I think it may be the first argument, because
MinGW64 define SOCKET as a pointer, but you accept int or unsigned int
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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-27 Thread Xiaobo Gu 
On Thu, Jan 27, 2011 at 10:44 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote:
 On Thu, Jan 27, 2011 at 9:32 PM, Andrew Dunstan and...@dunslane.net wrote:


 On 01/27/2011 07:56 AM, Xiaobo Gu wrote:

 Clearly there is a problem, or configure would have worked. You need to
 answer the question I asked previously, namely what is the declaration of
 accept() in the mingw64 headers? You have that source and I don't so I
 can't
 answer the question.

 #ifndef __WINSOCK_WS1_SHARED
 /* these 46 functions have the same prototypes as in winsock2 */
   WINSOCK_API_LINKAGE SOCKET WSAAPI accept(SOCKET s,struct sockaddr
 *addr,int *addrlen);
   WINSOCK_API_LINKAGE int WSAAPI bind(SOCKET s,const struct sockaddr
 *name,int namelen);
   WINSOCK_API_LINKAGE int WSAAPI closesocket(SOCKET s);
   WINSOCK_API_LINKAGE int WSAAPI connect(SOCKET s,const struct
 sockaddr *name,int namelen);

 Ok, now in src/config/ac_func_accept_argtypes.m4 on line 48, try adding the
 following alternatives for the return type:

   unsigned int WSAAPI
   int WSAAPI
   unsigned INT_PTR WSAAPI
   INT_PTR WSAAPI

 None of them works, I'll try to add  '__int64' as an option to first argument,

 and see if one of them lets configure pass.

AC_DEFUN([AC_FUNC_ACCEPT_ARGTYPES],
[AC_MSG_CHECKING([types of arguments for accept()])
 AC_CACHE_VAL(ac_cv_func_accept_return,dnl
 [AC_CACHE_VAL(ac_cv_func_accept_arg1,dnl
  [AC_CACHE_VAL(ac_cv_func_accept_arg2,dnl
   [AC_CACHE_VAL(ac_cv_func_accept_arg3,dnl
[for ac_cv_func_accept_return in 'INT_PTR WSAAPI' 'int' 'unsigned
int PASCAL'  ; do
  for ac_cv_func_accept_arg1 in '__int64' 'int' 'unsigned int' ; do
   for ac_cv_func_accept_arg2 in 'struct sockaddr *' 'const struct
sockaddr *' 'void *'; do
for ac_cv_func_accept_arg3 in 'int' 'size_t' 'socklen_t'
'unsigned int' 'void'; do
 AC_TRY_COMPILE(

The above combinition does not pass, another question,

Because I just want to build the client side of PostgreSQL, can I
ignore this error and let the configure pass

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

2011-01-27 Thread Xiaobo Gu 
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

2011-01-27 Thread Xiaobo Gu 
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

2011-01-27 Thread Xiaobo Gu 
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

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-25 Thread Xiaobo Gu 
Hi,
I have successfully built 32bit PostgreSQL 9.0.2 using 32bit GCC 4.5.0
and MinGW packaged by tdm64-gcc-4.5.1 from
http://tdm-gcc.tdragon.net/download.

But for 64bit there is only 4.5.1 GCC, which is not stable now, and
the configure script does not pass.

$ configure --without-zlib
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking which template to use... win32
checking whether to build with 64-bit integer date/time support... yes
checking whether NLS is wanted... no
checking for default port number... 5432
checking for block size... 8kB
checking for segment size... 1GB
checking for WAL block size... 8kB
checking for WAL segment size... 16MB
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking if gcc supports -Wdeclaration-after-statement... yes
checking if gcc supports -Wendif-labels... yes
checking if gcc supports -fno-strict-aliasing... yes
checking if gcc supports -fwrapv... yes
checking whether the C compiler still works... yes
checking how to run the C preprocessor... gcc -E
checking allow thread-safe client libraries... yes
checking whether to build with Tcl... no
checking whether to build Perl modules... no
checking whether to build Python modules... no
checking whether to build with GSSAPI support... no
checking whether to build with Kerberos 5 support... no
checking whether to build with PAM support... no
checking whether to build with LDAP support... no
checking whether to build with Bonjour support... no
checking whether to build with OpenSSL support... no
configure: WARNING: *** Readline does not work on MinGW --- disabling
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ld used by GCC... d:/amber/devtool/mingw64/x86_64-w64-mingw32/bin/l
d.exe
checking if the linker (d:/amber/devtool/mingw64/x86_64-w64-mingw32/bin/ld.exe)
is GNU ld... yes
checking for ranlib... ranlib
checking for strip... strip
checking whether it is possible to strip libraries... yes
checking for ar... ar
checking for dlltool... dlltool
checking for dllwrap... dllwrap
checking for windres... windres
checking for tar... /bin/tar
checking whether ln -s works... no, using cp -p
checking for gawk... gawk
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for bison... /bin/bison
configure: using bison (GNU Bison) 2.4.2
checking for flex... /bin/flex
configure: using flex 2.5.35
checking for perl... /bin/perl
configure: using perl 5.6.1
configure: 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: 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.)
checking for main in -lm... yes
checking for library containing setproctitle... no
checking for library containing dlopen... no
checking for library containing socket... -lwsock32
checking for library containing shl_load... no
checking for library containing getopt_long... none required
checking for library containing crypt... no
checking for library containing fdatasync... no
checking for library containing gethostbyname_r... no
checking for library containing shmget... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking crypt.h usability... no
checking crypt.h presence... no
checking for crypt.h... no
checking dld.h usability... no
checking dld.h presence... no
checking for dld.h... no
checking fp_class.h usability... no
checking fp_class.h presence... no
checking for fp_class.h... no
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking ieeefp.h usability... yes
checking ieeefp.h presence... yes
checking for ieeefp.h... yes
checking ifaddrs.h usability... no
checking ifaddrs.h presence... no
checking for ifaddrs.h... no
checking langinfo.h usability... no
checking langinfo.h presence... no
checking for langinfo.h... no
checking poll.h usability... no
checking poll.h presence... no
checking for poll.h... no
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking sys/ioctl.h usability... no
checking sys/ioctl.h

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-25 Thread Xiaobo Gu 
I also tried 64bit 4.5.2 GCC shipped with Rtools, the same error
 checking types of arguments for accept()... configure: error: could not 
 determin
 e argument types



On Tue, Jan 25, 2011 at 7:03 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote:
 Hi,
 I have successfully built 32bit PostgreSQL 9.0.2 using 32bit GCC 4.5.0
 and MinGW packaged by tdm64-gcc-4.5.1 from
 http://tdm-gcc.tdragon.net/download.

 But for 64bit there is only 4.5.1 GCC, which is not stable now, and
 the configure script does not pass.

 $ configure --without-zlib
 checking build system type... i686-pc-mingw32
 checking host system type... i686-pc-mingw32
 checking which template to use... win32
 checking whether to build with 64-bit integer date/time support... yes
 checking whether NLS is wanted... no
 checking for default port number... 5432
 checking for block size... 8kB
 checking for segment size... 1GB
 checking for WAL block size... 8kB
 checking for WAL segment size... 16MB
 checking for gcc... gcc
 checking for C compiler default output file name... a.exe
 checking whether the C compiler works... yes
 checking whether we are cross compiling... no
 checking for suffix of executables... .exe
 checking for suffix of object files... o
 checking whether we are using the GNU C compiler... yes
 checking whether gcc accepts -g... yes
 checking for gcc option to accept ISO C89... none needed
 checking if gcc supports -Wdeclaration-after-statement... yes
 checking if gcc supports -Wendif-labels... yes
 checking if gcc supports -fno-strict-aliasing... yes
 checking if gcc supports -fwrapv... yes
 checking whether the C compiler still works... yes
 checking how to run the C preprocessor... gcc -E
 checking allow thread-safe client libraries... yes
 checking whether to build with Tcl... no
 checking whether to build Perl modules... no
 checking whether to build Python modules... no
 checking whether to build with GSSAPI support... no
 checking whether to build with Kerberos 5 support... no
 checking whether to build with PAM support... no
 checking whether to build with LDAP support... no
 checking whether to build with Bonjour support... no
 checking whether to build with OpenSSL support... no
 configure: WARNING: *** Readline does not work on MinGW --- disabling
 checking for grep that handles long lines and -e... /bin/grep
 checking for egrep... /bin/grep -E
 checking for ld used by GCC... 
 d:/amber/devtool/mingw64/x86_64-w64-mingw32/bin/l
 d.exe
 checking if the linker 
 (d:/amber/devtool/mingw64/x86_64-w64-mingw32/bin/ld.exe)
 is GNU ld... yes
 checking for ranlib... ranlib
 checking for strip... strip
 checking whether it is possible to strip libraries... yes
 checking for ar... ar
 checking for dlltool... dlltool
 checking for dllwrap... dllwrap
 checking for windres... windres
 checking for tar... /bin/tar
 checking whether ln -s works... no, using cp -p
 checking for gawk... gawk
 checking for a thread-safe mkdir -p... /bin/mkdir -p
 checking for bison... /bin/bison
 configure: using bison (GNU Bison) 2.4.2
 checking for flex... /bin/flex
 configure: using flex 2.5.35
 checking for perl... /bin/perl
 configure: using perl 5.6.1
 configure: 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: 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.)
 checking for main in -lm... yes
 checking for library containing setproctitle... no
 checking for library containing dlopen... no
 checking for library containing socket... -lwsock32
 checking for library containing shl_load... no
 checking for library containing getopt_long... none required
 checking for library containing crypt... no
 checking for library containing fdatasync... no
 checking for library containing gethostbyname_r... no
 checking for library containing shmget... no
 checking for ANSI C header files... yes
 checking for sys/types.h... yes
 checking for sys/stat.h... yes
 checking for stdlib.h... yes
 checking for string.h... yes
 checking for memory.h... yes
 checking for strings.h... yes
 checking for inttypes.h... yes
 checking for stdint.h... yes
 checking for unistd.h... yes
 checking crypt.h usability... no
 checking crypt.h presence... no
 checking for crypt.h... no
 checking dld.h usability... no
 checking dld.h presence... no
 checking for dld.h... no
 checking fp_class.h usability... no
 checking fp_class.h presence... no
 checking for fp_class.h... no
 checking getopt.h usability... yes
 checking getopt.h presence... yes
 checking for getopt.h... yes
 checking ieeefp.h usability... yes
 checking ieeefp.h presence... yes
 checking for ieeefp.h... yes
 checking ifaddrs.h usability... no
 checking ifaddrs.h presence

Re: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-24 Thread Xiaobo Gu 
Hi,
According to http://www.pgbuildfarm.org/cgi-bin/show_status.pl, only
GCC 3.4.2 and 4.5.0 have successfully build PostgreSQL,and only under
32 bit Windows environment, and I guess from
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02073.php that
you mean we should only the above two versions of GCC to build
PostgreSQL, but my questions are:
1. I have 64bit GCC 4.5.0 installed before installing the lasted
MinGW, but after that the gcc version became to 3.4.4, which is not
support, how to change the GCC other versions than the one shipped
with MSYS.

2.You have only test 3.4.2 and 4.5.0 for 32 bit environments, do the
64 bit versions of GCC work under 64bit Windows?


Xiaobo Gu

On Mon, Jan 24, 2011 at 5:19 PM, Andrew Dunstan and...@dunslane.net wrote:


 On 01/23/2011 11:11 PM, Xiaobo Gu wrote:

 Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit
 Windows 7 home basic.
 Which version of 32bit MinGW  do you use, I use the one shipped with
 Rtools212.exe which is downloaded from
 http://www.murdoch-sutherland.com/Rtools, and there is no chmod.


 Please avoid top-answering on this list. I use the Mingw project's published
 files: http://sourceforge.net/projects/mingw/files/

 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

[HACKERS] Re: 答复: [HACKERS] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-23 Thread Xiaobo Gu 
Here is my plan,
1. To make the configurate script pass:
Currently MinGW does not provide chmod, but on Windows I think this
can be ignored now, we all use Admin
users to do the work.
2. To make a pg-client Makefile target, can you help wich which c
files should be compiled and linked into dlls and lib file.

Xiaobo Gu

2011/1/23 XiaoboGu guxiaobo1...@gmail.com:
 Hi

 I am not so familiar with the PostgreSQL development team, but using a MinGW
 compatible client side is important to us, so I'd like to start doing it
 myself if any of you experts can help.

 Cheers

 Xiaobo Gu

 -邮件原件-
 发件人: Andrew Dunstan [mailto:and...@dunslane.net]
 发送时间: 2011年1月21日 23:25
 收件人: Magnus Hagander
 抄送: Robert Haas; XiaoboGu; pgsql-hackers@postgresql.org
 主题: Re: [HACKERS] Is there a way to build PostgreSQL client libraries
 with MinGW



 On 01/21/2011 05:24 AM, Magnus Hagander wrote:
 
  That advice needs to be taken with a grain or two of salt. First, while
 you
  probably should not use Cygwin postgres as a production server, it is
 still
  the best way to run psql on Windows that I know of. And second, the
 stuff
  Yeah, I agree for psql the client tool (though it used to suck badly
  if you were in a non-english locale, but they may have fixed that).
  But not for PostgreSQL the full product. I guess we could add a
  sentence about the client side, but it needs to be clear that the
  non-sucky part only applies to the client.


 It's not so bad it can't be used for development, and I have known
 people who do that, and indeed I have deployed one very complex app
 developed in just that way.

 More importantly from my POV, there is no support in the buildfarm for
 just building the client side, and I have no intention of providing it.
 So it's not insignificant for us to be able to continue supporting a
 complete build on Cygwin, however much you dislike it.


 
  about not being able to generate 64-bit binaries with Mingw is no
 longer
  true (that's why it's no longer called Mingw32), although it is true
 that
  nobody I know has yet tried to do so. It's on my long TODO list, and
 well
  worth doing. (Relying on one compiler is the techno equivalent of
  monolingualism, which my sister's bumper sticker used to tell me is a
  curable condition.)
  It's true from the perspective of *postgresql* - you can't use those
  compiler to generate 64-bit binaries of PostgreSQL. And it's referring
  to these builds, not the compiler itself.
 
  And I'm certainly not going to stand in the way of somebody adding
  build support for it if they (you or others) want to spend time on it
  - that patch should just include an update to that documentation
  paragraph, of course.
 
  Personally, I'm going to put what time I can put into windows build
  system updates into making us work with VS 2010 because I find that
  more important - but that's just me personally.
 


 VS2010 is important, no doubt. But clearly there's some demand for
 continued Mingw support, hence the OP's question.

 As I've remarked before, I think we should support as many build
 platforms/environments as we can.

 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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-23 Thread Xiaobo Gu 
Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit
Windows 7 home basic.
Which version of 32bit MinGW  do you use, I use the one shipped with
Rtools212.exe which is downloaded from
http://www.murdoch-sutherland.com/Rtools, and there is no chmod.

xiaobo gu


2011/1/24 Andrew Dunstan and...@dunslane.net:


 On 01/23/2011 10:09 PM, Xiaobo Gu wrote:
 Here is my plan,
 1. To make the configurate script pass:
       Currently MinGW does not provide chmod, but on Windows I think this
 can be ignored now, we all use Admin
       users to do the work.
 2. To make a pg-client Makefile target, can you help wich which c
 files should be compiled and linked into dlls and lib file.



 Why do you need to do this? Postgres can be built as is today on Mingw.
 Not just the client libraries, the whole server too. It does not need to
 be an Adminstrative user, and you should by no means assume that the
 user building Postgres will be an administrator, nor that the user
 running Postgres will be. My 32 bit Mingw certainly understands chmod.

 There are machines doing this every day, several times a day. See
 http://www.pgbuildfarm.org/cgi-bin/show_status.pl - frogmouth and
 narwhal are examples. We've had working Mingw builds for quite a few
 years now.

 The only issue is building 64bit binaries. So get the build working for
 32bit, then try switching to the 64bit compiler and see what breaks. If
 all you need is the client library, build with no zlib or any other
 third party libraries.

 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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-23 Thread Xiaobo Gu 
/sys/errno.h:114:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:255:1: warning: EINPROGRESS redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:129:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:256:1: warning: ENOBUFS redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:115:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:257:1: warning: EPROTONOSUPPORT redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:133:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:258:1: warning: ECONNREFUSED redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:121:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:259:1: warning: EBADFD redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:100:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:90,
 from crypt.c:44:
../../src/include/pg_config_os.h:260:1: warning: EOPNOTSUPP redefined
In file included from /usr/include/errno.h:1,
 from ../../src/include/c.h:80,
 from crypt.c:44:
/usr/include/sys/errno.h:112:1: warning: this is the location of the previous de
finition
In file included from ../../src/include/c.h:851,
 from crypt.c:44:
../../src/include/port.h:420: warning: struct passwd declared inside parameter
 list
../../src/include/port.h:420: warning: its scope is only this definition or decl
aration, which is probably not what you want
make[2]: *** [crypt.o] Error 1
make[2]: Leaving directory `/d/devproj/postgresql-9.0.2/src/port'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/d/devproj/postgresql-9.0.2/src'
make: *** [all] Error 2





On Mon, Jan 24, 2011 at 12:11 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote:
 Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit
 Windows 7 home basic.
 Which version of 32bit MinGW  do you use, I use the one shipped with
 Rtools212.exe which is downloaded from
 http://www.murdoch-sutherland.com/Rtools, and there is no chmod.

 xiaobo gu


 2011/1/24 Andrew Dunstan and...@dunslane.net:


 On 01/23/2011 10:09 PM, Xiaobo Gu wrote:
 Here is my plan,
 1. To make the configurate script pass:
       Currently MinGW does not provide chmod, but on Windows I think this
 can be ignored now, we all use Admin
       users to do the work.
 2. To make a pg-client Makefile target, can you help wich which c
 files should be compiled and linked into dlls and lib file.



 Why do you need to do this? Postgres can be built as is today on Mingw.
 Not just the client libraries, the whole server too. It does not need to
 be an Adminstrative user, and you should by no means assume that the
 user building Postgres will be an administrator, nor that the user
 running Postgres will be. My 32 bit Mingw certainly understands chmod.

 There are machines doing this every day, several times a day. See
 http://www.pgbuildfarm.org/cgi-bin/show_status.pl - frogmouth and
 narwhal are examples. We've had working Mingw builds for quite a few
 years now.

 The only issue is building 64bit binaries. So get the build working for
 32bit, then try switching to the 64bit compiler and see what breaks. If
 all you need is the client library, build with no zlib or any other
 third party libraries.

 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] Is there a way to build PostgreSQL client libraries with MinGW

2011-01-23 Thread Xiaobo Gu 
And there are two versions of gcc installed on my WinXP PRO SP3, 3.4.4
is the one used to the above test

D:\devproj\postgresql-9.0.2gcc -v
Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs
Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --s
ysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man --
libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix --
enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug --
with-newlib
Thread model: posix
gcc version 3.4.4 (msys special)

D:\devproj\postgresql-9.0.2


D:\Amber\Program\Rtools211\MinGW\bingcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: mingw32
Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r
untime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 (GCC)

D:\Amber\Program\Rtools211\MinGW\bin

On Mon, Jan 24, 2011 at 1:17 PM, Xiaobo Gu guxiaobo1...@gmail.com wrote:
 Hi,
 I download the lastest 32bit MinGW from sourceforge, and found there
 are *NIX like tools such as chmod and ls in the MinGW\msys\1.0\bin
 directory.


 But the make process does not success,

 This test is done on my 32bit Windows XP SP3

 Here are the messages:

 D:\devproj\postgresql-9.0.2sh configure --without-zlib
 ..

 D:\devproj\postgresql-9.0.2ls
 2011-01-24  13:14    DIR          .
 2011-01-24  13:14    DIR          ..
 2010-12-14  10:55               233 .gitignore
 2010-12-14  10:55               445 aclocal.m4
 2011-01-24  11:12    DIR          config
 2011-01-24  13:14           478,602 config.log
 2011-01-24  13:14            36,977 config.status
 2010-12-14  10:55           844,733 configure
 2010-12-14  10:55            60,877 configure.in
 2011-01-24  12:06           840,095 configure.lineno
 2011-01-24  11:12    DIR          contrib
 2010-12-14  10:55             1,192 COPYRIGHT
 2011-01-24  11:12    DIR          doc
 2011-01-24  13:14             3,760 GNUmakefile
 2010-12-14  10:55             3,760 GNUmakefile.in
 2010-12-14  11:21           968,292 HISTORY
 2010-12-14  11:21            79,024 INSTALL
 2010-12-14  10:55             1,477 Makefile
 2010-12-14  10:55             1,287 README
 2011-01-24  13:14    DIR          src

 D:\devproj\postgresql-9.0.2make
 make -C src all
 make[1]: Entering directory `/d/devproj/postgresql-9.0.2/src'
 make -C port all
 make[2]: Entering directory `/d/devproj/postgresql-9.0.2/src/port'
 gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
 -Wdeclaration-after-statement
  -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND 
 -I../..
 /src/include -I./src/include/port/win32 -DEXEC_BACKEND  
 -I../../src/include/por
 t/win32  -c -o fseeko.o fseeko.c
 gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
 -Wdeclaration-after-statement
  -Wendif-labels -fno-strict-aliasing -fwrapv -I../../src/port -DFRONTEND 
 -I../..
 /src/include -I./src/include/port/win32 -DEXEC_BACKEND  
 -I../../src/include/por
 t/win32  -c -o crypt.o crypt.c
 In file included from ../../src/include/pg_config_os.h:22,
                 from ../../src/include/c.h:90,
                 from crypt.c:44:
 /usr/lib/gcc/i686-pc-msys/3.4.4/../../../../include/w32api/winsock2.h:103:2: 
 war
 ning: #warning fd_set and associated macros have been defined in sys/types.
  This may cause runtime problems with W32 sockets
 In file included from ../../src/include/c.h:90,
                 from crypt.c:44:
 ../../src/include/pg_config_os.h:28:20: direct.h: No such file or directory
 ../../src/include/pg_config_os.h:90:1: warning: EIDRM redefined
 In file included from /usr/include/errno.h:1,
                 from ../../src/include/c.h:80,
                 from crypt.c:44:
 /usr/include/sys/errno.h:64:1: warning: this is the location of the previous 
 def
 inition
 In file included from ../../src/include/c.h:90,
                 from crypt.c:44:
 ../../src/include/pg_config_os.h:165:1: warning: SIGABRT redefined
 In file included from /usr/include/signal.h:8,
                 from ../../src/include/pg_config_os.h:26,
                 from ../../src/include/c.h:90,
                 from crypt.c:44:
 /usr/include/sys/signal.h:225:1: warning: this is the location of the 
 previous d
 efinition
 In file included from ../../src/include/c.h:90,
                 from crypt.c:44:
 ../../src/include/pg_config_os.h:222: error: conflicting types for 'uid_t'
 /usr/include/sys/types.h:133: error: previous declaration of 'uid_t' was here
 ../../src/include/pg_config_os.h:223: error: conflicting types for 'gid_t'
 /usr/include/sys/types.h:134: error: previous declaration of 'gid_t' was here
 In file included from ../../src/include/c.h:90,
                 from crypt.c:44:
 ../../src/include/pg_config_os.h:251:1: warning: EMSGSIZE