Re: Is there a way to build PostgreSQL client libraries with MinGW - Mailing list pgsql-hackers

From Xiaobo Gu
Subject Re: Is there a way to build PostgreSQL client libraries with MinGW
Date
Msg-id AANLkTi=w0G-pbzezd5b_3c_0MobmhG_e1suhjwFvdLH5@mail.gmail.com
Whole thread Raw
In response to Is there a way to build PostgreSQL client libraries with MinGW  ("XiaoboGu" <guxiaobo1982@gmail.com>)
List pgsql-hackers
On Thu, Jan 27, 2011 at 9:14 PM, Xiaobo Gu <guxiaobo1982@gmail.com> wrote:
> On Thu, Jan 27, 2011 at 8:56 PM, Xiaobo Gu <guxiaobo1982@gmail.com> wrote:
>> On Thu, Jan 27, 2011 at 8:51 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>>
>>>
>>> On 01/27/2011 07:41 AM, Xiaobo Gu wrote:
>>>>
>>>> On Thu, Jan 27, 2011 at 8:37 PM, Andrew Dunstan<andrew@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: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
>>>>>>
>>>>>
>>>>>
>>>>> 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;
typedefunsigned long ULONG_PTR,*PULONG_PTR; 
#define __int3264 __int32
#endif

> Xiaobo Gu
>


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: sepgsql contrib module
Next
From: Dimitri Fontaine
Date:
Subject: Re: Extensions support for pg_dump, patch v27