Re: [HACKERS] Notes about fixing regexes and UTF-8 (yet again)

2012-02-18 Thread NISHIYAMA Tomoaki

I don't believe it is valid to ignore CJK characters above U+2.
If it is used for names, it will be stored in the database.
If the behaviour is different from characters below U+, you will
get a bug report in meanwhile.

see
CJK Extension B, C, and D
from
http://www.unicode.org/charts/

Also, there are some code points that could be regarded alphabet and numbers
http://en.wikipedia.org/wiki/Mathematical_alphanumeric_symbols

On the other hand, it is ok if processing of characters above U+1 is very 
slow, 
as far as properly processed, because it is considered rare.


On 2012/02/17, at 23:56, Andrew Dunstan wrote:

 
 
 On 02/17/2012 09:39 AM, Tom Lane wrote:
 Heikki Linnakangasheikki.linnakan...@enterprisedb.com  writes:
 Here's a wild idea: keep the class of each codepoint in a hash table.
 Initialize it with all codepoints up to 0x. After that, whenever a
 string contains a character that's not in the hash table yet, query the
 class of that character, and add it to the hash table. Then recompile
 the whole regex and restart the matching engine.
 Recompiling is expensive, but if you cache the results for the session,
 it would probably be acceptable.
 Dunno ... recompiling is so expensive that I can't see this being a win;
 not to mention that it would require fundamental surgery on the regex
 code.
 
 In the Tcl implementation, no codepoints above U+ have any locale
 properties (alpha/digit/punct/etc), period.  Personally I'd not have a
 problem imposing the same limitation, so that dealing with stuff above
 that range isn't really a consideration anyway.
 
 
 up to U+ is the BMP which is described as containing characters for 
 almost all modern languages, and a large number of special characters. It 
 seems very likely to be acceptable not to bother about the locale of code 
 points in the supplementary planes.
 
 See http://en.wikipedia.org/wiki/Plane_%28Unicode%29 for descriptions of 
 which sets of characters are involved.
 
 
 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
 


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-12-08 Thread NISHIYAMA Tomoaki
Hi,

 FYI I've been testing with the attached patch.
 We'll need to construct a configure test for HAVE_CRTDEFS_H.

Isn't it enough to add the name in configure.in and run autoconf to 
update configure and autoheaders to update pg_config.h.in?
The check of win32 before large file perhaps should also go to configure.in, 
otherwise they would be wiped with next autoconf.

The patch recreated with removing the #undef
but adding the conditional to skip AC_SYS_LARGEFILE in configure.in and 
update configure by autoconf.

diff --git a/config/ac_func_accept_argtypes.m4 
b/config/ac_func_accept_argtypes.m4
index 1e77179..a82788d 100644
--- a/config/ac_func_accept_argtypes.m4
+++ b/config/ac_func_accept_argtypes.m4
@@ -46,7 +46,7 @@ AC_DEFUN([AC_FUNC_ACCEPT_ARGTYPES],
  [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' 'unsigned int PASCAL' 'SOCKET'; do
+[for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL' 'SOCKET 
WSAAPI'; do
   for ac_cv_func_accept_arg1 in 'int' 'unsigned int' 'SOCKET'; 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
diff --git a/configure b/configure
index de9ba5a..dfdd034 100755
--- a/configure
+++ b/configure
@@ -10056,7 +10056,8 @@ done
 
 
 
-for ac_header in crypt.h dld.h fp_class.h getopt.h ieeefp.h ifaddrs.h 
langinfo.h poll.h pwd.h sys/ioctl.h sys/ipc.h sys/poll.h sys/pstat.h 
sys/resource.h sys/select.h sys/sem.h sys/shm.h sys/socket.h sys/sockio.h 
sys/tas.h sys/time.h sys/ucred.h sys/un.h termios.h ucred.h utime.h wchar.h 
wctype.h kernel/OS.h kernel/image.h SupportDefs.h
+
+for ac_header in crypt.h dld.h fp_class.h getopt.h ieeefp.h ifaddrs.h 
langinfo.h poll.h pwd.h sys/ioctl.h sys/ipc.h sys/poll.h sys/pstat.h 
sys/resource.h sys/select.h sys/sem.h sys/shm.h sys/socket.h sys/sockio.h 
sys/tas.h sys/time.h sys/ucred.h sys/un.h termios.h ucred.h utime.h wchar.h 
wctype.h kernel/OS.h kernel/image.h SupportDefs.h crtdefs.h
 do
 as_ac_Header=`$as_echo ac_cv_header_$ac_header | $as_tr_sh`
 if { as_var=$as_ac_Header; eval test \\${$as_var+set}\ = set; }; then
@@ -17997,6 +17998,7 @@ fi
 # compiler characteristic, but you'd be wrong.  We must check this before
 # probing existence of related functions such as fseeko, since the largefile
 # defines can affect what is generated for that.
+if test $PORTNAME != win32 ; then
 # Check whether --enable-largefile was given.
 if test ${enable_largefile+set} = set; then
   enableval=$enable_largefile;
@@ -18353,7 +18355,7 @@ rm -rf conftest*
   fi
 fi
 
-
+fi
 # Check for largefile support (must be after AC_SYS_LARGEFILE)
 # The cast to long int works around a bug in the HP C Compiler
 # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects
@@ -18808,7 +18810,7 @@ else
  if test ${ac_cv_func_accept_arg3+set} = set; then
   $as_echo_n (cached)  6
 else
-  for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL' 'SOCKET'; do
+  for ac_cv_func_accept_return in 'int' 'unsigned int PASCAL' 'SOCKET 
WSAAPI'; do
   for ac_cv_func_accept_arg1 in 'int' 'unsigned int' 'SOCKET'; 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
diff --git a/configure.in b/configure.in
index 5591b93..79180df 100644
--- a/configure.in
+++ b/configure.in
@@ -985,7 +985,7 @@ AC_SUBST(OSSP_UUID_LIBS)
 ##
 
 dnl sys/socket.h is required by AC_FUNC_ACCEPT_ARGTYPES
-AC_CHECK_HEADERS([crypt.h dld.h fp_class.h getopt.h ieeefp.h ifaddrs.h 
langinfo.h poll.h pwd.h sys/ioctl.h sys/ipc.h sys/poll.h sys/pstat.h 
sys/resource.h sys/select.h sys/sem.h sys/shm.h sys/socket.h sys/sockio.h 
sys/tas.h sys/time.h sys/ucred.h sys/un.h termios.h ucred.h utime.h wchar.h 
wctype.h kernel/OS.h kernel/image.h SupportDefs.h])
+AC_CHECK_HEADERS([crypt.h dld.h fp_class.h getopt.h ieeefp.h ifaddrs.h 
langinfo.h poll.h pwd.h sys/ioctl.h sys/ipc.h sys/poll.h sys/pstat.h 
sys/resource.h sys/select.h sys/sem.h sys/shm.h sys/socket.h sys/sockio.h 
sys/tas.h sys/time.h sys/ucred.h sys/un.h termios.h ucred.h utime.h wchar.h 
wctype.h kernel/OS.h kernel/image.h SupportDefs.h crtdefs.h])
 
 # On BSD, cpp test for net/if.h will fail unless sys/socket.h
 # is included first.
@@ -1174,8 +1174,9 @@ fi
 # compiler characteristic, but you'd be wrong.  We must check this before
 # probing existence of related functions such as fseeko, since the largefile
 # defines can affect what is generated for that.
+if test $PORTNAME != win32 ; then
 AC_SYS_LARGEFILE
-
+fi
 # Check for largefile support (must be after AC_SYS_LARGEFILE)
 AC_CHECK_SIZEOF([off_t])
 
diff --git a/src/include/c.h b/src/include/c.h
index 0391860..14f6443 100644
--- a/src/include/c.h
+++ b/src/include/c.h
@@ 

Re: [HACKERS] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-12-05 Thread NISHIYAMA Tomoaki
Hi,

If we are not to use 64 bit file size (and time),
#undef stat may be sufficient. The #undef should be
before the prototype of pgwin32_safestat because the
#define stat _stat64 affect both the function and struct stat.
The #undef stat necessitate #undef fstat as the parameter
struct stat * is changed.

Additional change are for the macro redefinition warnings.
(Suppress warnings, but perhaps not very different)

The patch is tested to compile on 
x86_64-w64-mingw32-gcc 4.7.0 20111203 (experimental)
and
gcc version 4.6.1 on MingW/MSYS

--- a/src/include/port.h
+++ b/src/include/port.h
@@ -334,6 +334,12 @@ extern bool rmtree(const char *path, bool rmtopdir);
  */
 #if defined(WIN32)  !defined(__CYGWIN__)  !defined(UNSAFE_STAT_OK)
 #include sys/stat.h
+#ifdef stat
+#undef stat
+#endif
+#ifdef fstat
+#undef fstat
+#endif
 extern int pgwin32_safestat(const char *path, struct stat * buf);
 
 #define stat(a,b) pgwin32_safestat(a,b)


If this is not sufficient, we might need to change all call of stat, lstat, and 
fstat
to some wrapper functions?  : It's theoretically doable, but could be quite 
difficult
for a huge software.



pgsql-mingw64-patch.diff
Description: Binary data

On 2011/12/05, at 1:10, Andrew Dunstan wrote:

 
 
 On 12/04/2011 06:31 AM, Magnus Hagander wrote:
 On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
 tomoa...@staff.kanazawa-u.ac.jp  wrote:
 Hi,
 
 I found error on #define stat _stat64 occurs on Mingw-w64 
 (x86_64-w64-mingw32)
 gcc version 4.7.0 20111203 (experimental) (GCC)
 
 The code can be compiled with
 
 diff --git a/src/include/port.h b/src/include/port.h
 index eceb4bf..78d5c92 100644
 --- a/src/include/port.h
 +++ b/src/include/port.h
 @@ -332,7 +332,7 @@ extern bool rmtree(const char *path, bool rmtopdir);
  * Some frontends don't need the size from stat, so if UNSAFE_STAT_OK
  * is defined we don't bother with this.
  */
 -#if defined(WIN32)  !defined(__CYGWIN__)  !defined(UNSAFE_STAT_OK)
 +#if defined(WIN32_ONLY_COMPILER)  !defined(UNSAFE_STAT_OK)
  #includesys/stat.h
  extern int pgwin32_safestat(const char *path, struct stat * buf);
 
 but, surely we need to know if it is ok or not
 as the comment before says:
  * stat() is not guaranteed to set the st_size field on win32, so we
  * redefine it to our own implementation that is.
 
 Is there any simple test program that determines if the pgwin32_safestat
 is required or the library stat is sufficient?
 I presume the stat is a library function and therefore it depends on the
 compiler rather than the WIN32 platform as a whole.
 No, stat() is unreliable because it is implemented on top of
 FindNextFile(), and *that's* where the actual problem is at. And
 that's an OS API function, not a library function. See the discussion
 at http://archives.postgresql.org/pgsql-hackers/2008-03/msg01181.php
 
 In theory, if mingw implemented their stat() without using
 FindNextFile(), it might work - but I don't see how they'd do it in
 that case. And I can't see us going into details to remove such a
 simple workaround even if they do - it's better to ensure we work the
 same way with different compilers.
 
 
 
 Yeah.
 
 
 This is only a problem because, with this compiler, configure finds this:
 
   checking for _FILE_OFFSET_BITS value needed for large files... 64
   checking size of off_t... 8
 
 whereas on the mingw-w64 compiler pitta is using it finds this:
 
   checking for _FILE_OFFSET_BITS value needed for large files... unknown
   checking for _LARGE_FILES value needed for large files... unknown
   checking size of off_t... 4
 
 
 It's the setting of _FILE_OFFSET_BITS that causes the offending macro 
 definition.
 
 Can we just turn off largefile support for this compiler, or maybe for all 
 mingw builds, possibly by just disabling the checks in configure.in? I note 
 it's turned off for MSVC in all flavors apparently. pgwin32_safestat() isn't 
 safe for large files anyway, so there would be good grounds for doing so 
 quite apart from this, ISTM. (Of course, we should work out how to handle 
 large files properly on Windows, but that's a task for another day.)
 
 (BTW, someone asked me the other day why anyone would want to do 32 bit 
 builds. One answer is that often the libraries you want to link with are only 
 available in 32 bit versions.)
 
 
 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
 


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-12-04 Thread NISHIYAMA Tomoaki
Hi,

I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
gcc version 4.7.0 20111203 (experimental) (GCC)

The code can be compiled with 

diff --git a/src/include/port.h b/src/include/port.h
index eceb4bf..78d5c92 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -332,7 +332,7 @@ extern bool rmtree(const char *path, bool rmtopdir);
  * Some frontends don't need the size from stat, so if UNSAFE_STAT_OK
  * is defined we don't bother with this.
  */
-#if defined(WIN32)  !defined(__CYGWIN__)  !defined(UNSAFE_STAT_OK)
+#if defined(WIN32_ONLY_COMPILER)  !defined(UNSAFE_STAT_OK)
 #include sys/stat.h
 extern int pgwin32_safestat(const char *path, struct stat * buf);
 
but, surely we need to know if it is ok or not
as the comment before says:
 * stat() is not guaranteed to set the st_size field on win32, so we
 * redefine it to our own implementation that is.

Is there any simple test program that determines if the pgwin32_safestat
is required or the library stat is sufficient?
I presume the stat is a library function and therefore it depends on the
compiler rather than the WIN32 platform as a whole.


On 2011/12/04, at 12:55, NISHIYAMA Tomoaki wrote:

 Hi,
 
 On 2011/12/04, at 9:45, Andrew Dunstan wrote:
 Yes, but there's a deal more work to do here. This whole thing is falling 
 over in my build environment (64 bit Windows 7, MinGW/MSys, the machine 
 that runs pitta on the buildfarm.)
 
 This is a long way from a done deal.
 
 In particular, it's a major mess because it does this (or at least the 
 version I'm using does):
 
  #define stat _stat64
 
 which plays merry hell with pgwin32_safestat(). Working around that looks 
 very unpleasant indeed.
 
 
 Thank you for testing and reporting.
 Would you mind giving me a bit more information on the environment?
 --especially for the MinGW/MSYS versions and any other component that is 
 required.
 
 I tested on a virtual machine running 64 bit Windows 7 SP1,
 installing MinGW/MSYS in the clean state and then compile.  
 The versions coming with pre-packaged repository catalogues of 20110802
 (gcc 4.5.2) and latest catalogue (gcc-4.6.1-2) compiles successfully.
 
 
 On 2011/12/04, at 9:45, Andrew Dunstan wrote:
 
 
 
 On 12/03/2011 06:12 PM, Andrew Dunstan wrote:
 
 
 On 12/03/2011 09:59 AM, Magnus Hagander wrote:
 On Sat, Dec 3, 2011 at 15:49, NISHIYAMA Tomoaki
 tomoa...@staff.kanazawa-u.ac.jp  wrote:
 Hi,
 
 Have you verified if tihs affects _MSC_VER  1400? Suddently that
 branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
 something we need to worry about.
 
 I have no MSVC. In that sense it is not verified in fact, and I hope
 those who knows well would kindly comment on it.
 
 However, it appears that pg_config.h is not created through
 configure, but just copied from pg_config.h.win32 in those
 compilers and thus HAVE_CRTDEFS_H will not be defined.
 So, I think this code fragment will not be enabled in
 _MSC_VER  1400
 Hmm, true. Unless HAVE_CRTDEFS_H is defined by the sytem, which it
 likely isn't - I was confusing it with the kind of defines that MSVC
 tends to stick in their own headerfiles, and thought that's what you
 were testing for.
 
 
 
 Yes, but there's a deal more work to do here. This whole thing is falling 
 over in my build environment (64 bit Windows 7, MinGW/MSys, the machine 
 that runs pitta on the buildfarm.)
 
 This is a long way from a done deal.
 
 
 In particular, it's a major mess because it does this (or at least the 
 version I'm using does):
 
  #define stat _stat64
 
 
 which plays merry hell with pgwin32_safestat(). Working around that looks 
 very unpleasant indeed.
 
 
 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
 
 
 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers
 


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-12-03 Thread NISHIYAMA Tomoaki
Hi,

A new patch:
check for the presence of crtdefs.h in configure

-#if _MSC_VER = 1400 || defined(WIN64)
+#if _MSC_VER = 1400 || HAVE_CRTDEFS_H
 #define errcode __msvc_errcode
 #include crtdefs.h
 #undef errcode

Perhaps there is no guarantee that mingw (not -w64) may not have crtdefs.h in 
the future versions.
the 3 lines
 #define errcode __msvc_errcode
 #include crtdefs.h
 #undef errcode
should be valid as far as crtdefs.h exists and errcode is not defined 
previously.
Because this is the first system include file, we can be sure errcode is not 
defined by this point.
So, I believe its better to just test for the presence of crtdefs.h rather than
try to figure out the name of compiler.

check for fseeko and ftello macro definition before defining to avoid
warning in mingw-w64 4.7.0 20110827

This patch was tested to build successfully on
mingw gcc version 4.6.1
mingw-w64 i686-w64-mingw32 gcc version 4.5.4 20110812
mingw-w64 x86_64-w64-mingw32 gcc version 4.7.0 20110827



mingw64-32bitpatch.diff
Description: Binary data




On 2011/12/02, at 1:29, Andrew Dunstan wrote:

 
 
 On 11/27/2011 09:18 AM, NISHIYAMA Tomoaki wrote:
 Hi,
 
 +/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
 + * mingw-w64, however it gots defined only after
 Why not use __MINGW32__, which is defined without including any headers?
 Because it's defined by other than mingw-w64 compilers.
 I see. That's because mingw (not -w64).
 Should it be ok if mingw is ok with that condition?
 
 This really breaks mingw gcc 4.6.1 :( it does not have crtdefs.h)
 If moving downward do not break MSVC, perhaps its the good way.
 Otherwise, we might check for the presence of crtdefs.h with configure?
 
 
 
 I have looked at this a bit. It's fairly ugly, and the only moderately clean 
 way I see forward is a configure test to check for a mingw-w64 compiler, e.g. 
 by running gcc -E -dM over a file which just includes stdio.h and checking 
 for the definedness of __MINGW64__VERSION_MAJOR, or something similar.
 
 
 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
 


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-12-03 Thread NISHIYAMA Tomoaki
Hi,

 Have you verified if tihs affects _MSC_VER  1400? Suddently that
 branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
 something we need to worry about.


I have no MSVC. In that sense it is not verified in fact, and I hope
those who knows well would kindly comment on it.

However, it appears that pg_config.h is not created through
configure, but just copied from pg_config.h.win32 in those
compilers and thus HAVE_CRTDEFS_H will not be defined.
So, I think this code fragment will not be enabled in
_MSC_VER  1400

In addition, the code fragment should have no harm as far as they
have crtdefs.h.
(Again, this is I think it should, and not tested with real tools.)

On 2011/12/03, at 23:20, Magnus Hagander wrote:

 On Sat, Dec 3, 2011 at 09:24, NISHIYAMA Tomoaki
 tomoa...@staff.kanazawa-u.ac.jp wrote:
 Hi,
 
 A new patch:
 check for the presence of crtdefs.h in configure
 
 -#if _MSC_VER = 1400 || defined(WIN64)
 +#if _MSC_VER = 1400 || HAVE_CRTDEFS_H
  #define errcode __msvc_errcode
  #include crtdefs.h
  #undef errcode
 
 Have you verified if tihs affects _MSC_VER  1400? Suddently that
 branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
 something we need to worry about.
 
 -- 
  Magnus Hagander
  Me: http://www.hagander.net/
  Work: http://www.redpill-linpro.com/
 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers
 


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-12-03 Thread NISHIYAMA Tomoaki
Hi,

On 2011/12/04, at 9:45, Andrew Dunstan wrote:
 Yes, but there's a deal more work to do here. This whole thing is falling 
 over in my build environment (64 bit Windows 7, MinGW/MSys, the machine that 
 runs pitta on the buildfarm.)
 
 This is a long way from a done deal.
 
 In particular, it's a major mess because it does this (or at least the 
 version I'm using does):
 
   #define stat _stat64
 
 which plays merry hell with pgwin32_safestat(). Working around that looks 
 very unpleasant indeed.


Thank you for testing and reporting.
Would you mind giving me a bit more information on the environment?
--especially for the MinGW/MSYS versions and any other component that is 
required.

I tested on a virtual machine running 64 bit Windows 7 SP1,
installing MinGW/MSYS in the clean state and then compile.  
The versions coming with pre-packaged repository catalogues of 20110802
(gcc 4.5.2) and latest catalogue (gcc-4.6.1-2) compiles successfully.


On 2011/12/04, at 9:45, Andrew Dunstan wrote:

 
 
 On 12/03/2011 06:12 PM, Andrew Dunstan wrote:
 
 
 On 12/03/2011 09:59 AM, Magnus Hagander wrote:
 On Sat, Dec 3, 2011 at 15:49, NISHIYAMA Tomoaki
 tomoa...@staff.kanazawa-u.ac.jp  wrote:
 Hi,
 
 Have you verified if tihs affects _MSC_VER  1400? Suddently that
 branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
 something we need to worry about.
 
 I have no MSVC. In that sense it is not verified in fact, and I hope
 those who knows well would kindly comment on it.
 
 However, it appears that pg_config.h is not created through
 configure, but just copied from pg_config.h.win32 in those
 compilers and thus HAVE_CRTDEFS_H will not be defined.
 So, I think this code fragment will not be enabled in
 _MSC_VER  1400
 Hmm, true. Unless HAVE_CRTDEFS_H is defined by the sytem, which it
 likely isn't - I was confusing it with the kind of defines that MSVC
 tends to stick in their own headerfiles, and thought that's what you
 were testing for.
 
 
 
 Yes, but there's a deal more work to do here. This whole thing is falling 
 over in my build environment (64 bit Windows 7, MinGW/MSys, the machine that 
 runs pitta on the buildfarm.)
 
 This is a long way from a done deal.
 
 
 In particular, it's a major mess because it does this (or at least the 
 version I'm using does):
 
   #define stat _stat64
 
 
 which plays merry hell with pgwin32_safestat(). Working around that looks 
 very unpleasant indeed.
 
 
 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
 


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-11-27 Thread NISHIYAMA Tomoaki
Hi,

 For the win32.h, I really don't understand why _WINSOCKAPI_ was defined 
 before
 winsock2.h
 some google suggests that defining _WINSOCKAPI_ beforewindows.h  prevents
 inclusion of winsock.h but that does not have relation to inclusion of
 winsock2.h  and ifwinsock2.h  is included first, it should be ok.
 
 If this guess is right, perhaps it could be better to remove the three 
 lines.
 #if !defined(WIN64) || defined(WIN32_ONLY_COMPILER)
 #define _WINSOCKAPI_
 #endif
 
 No, this broke some compilers, IIRC (probably the native mingw compiler, 
 which is in use by several buildfarm members). Getting this right was very 
 tricky and time-consuming when I was adding support for the 64 bit mingw-w64 
 compiler, and there were a couple of rounds of breakage.
 
 I'm therefore much more inclined to go the way of your earlier patch, which 
 seems much less risky.


I agree that original patch could be less risky. 
However, it doesn't match what Microsoft says:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737629%28v=vs.85%29.aspx

So, I think the standard way is not defining _WINSOCKAPI_, and if any compiler 
requires that,
which I think unlikely, then it should be defined as a exceptional case.
At least, native mingw GCC 4.5.2 (20110802 catalogue) and
4.6.1 (latest catalogue) does compile happily without the three lines.

 I only changed this for consistency. For me, it works without that define in 
 all test
 environments, too.
 
 +/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
 + * mingw-w64, however it gots defined only after
 Why not use __MINGW32__, which is defined without including any headers?
 
 Because it's defined by other than mingw-w64 compilers.

I see. That's because mingw (not -w64). 
Should it be ok if mingw is ok with that condition?

 We have a bunch of compilers to support here. There are LOTS of compiler 
 scenarios on Windows (several versions of MSVC, 32bit and 64bit mingw-w64, 
 native mingw gcc, and a couple of Cygwin based compilers), and keeping track 
 of them all and making sure they don't break can be a pain.


Yes, that really is a pain.

The code block
#if _MSC_VER = 1400 || defined(WIN64)
#define errcode __msvc_errcode
#include crtdefs.h
#undef errcode
#endif

looks as if there is no real need to crtdefs.h but, they wanted to prevent
definition of errcode and therefor put to the first place.

So, I was afraid moving the include downwards might break by 
by including a header that internally includes crtdefs.h.
If this is not problematic for MSVC (perhaps you know better on that),  
I have no objection in moving the order.


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-11-27 Thread NISHIYAMA Tomoaki
Hi,

 +/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
 + * mingw-w64, however it gots defined only after
 Why not use __MINGW32__, which is defined without including any headers?
 
 Because it's defined by other than mingw-w64 compilers.
 
 I see. That's because mingw (not -w64). 
 Should it be ok if mingw is ok with that condition?


This really breaks mingw gcc 4.6.1 :( it does not have crtdefs.h)
If moving downward do not break MSVC, perhaps its the good way.
Otherwise, we might check for the presence of crtdefs.h with configure?


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-11-24 Thread NISHIYAMA Tomoaki
Hi,

Isn't it better to check the value of macros itsef rather than checking for
system dependent macros that does not directly relate to the issue?
specifically for getaddrinfo.c case I think
#if EAI_NODATA != EAI_NONAME
is a better check than checking for
#if !defined(__MINGW64_VERSION_MAJOR)  !defined(WIN32_ONLY_COMPILER)  /* 
MSVC/WIN64 duplicate */

For the win32.h, I really don't understand why _WINSOCKAPI_ was defined before
winsock2.h
some google suggests that defining _WINSOCKAPI_ before windows.h prevents
inclusion of winsock.h but that does not have relation to inclusion of
winsock2.h and if winsock2.h is included first, it should be ok.

If this guess is right, perhaps it could be better to remove the three lines.
#if !defined(WIN64) || defined(WIN32_ONLY_COMPILER)
#define _WINSOCKAPI_
#endif

+/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
+ * mingw-w64, however it gots defined only after
Why not use __MINGW32__, which is defined without including any headers?


On 2011/11/24, at 17:24, Lars Kanis wrote:

 Hi PostgreSQL hackers,
  
 support for Mingw-w64 compiler was added to postgres with commit 91812df. 
 Unfortunately only the 64 bit output is working right now. This issue was 
 already highlighted with initial patch in
 http://archives.postgresql.org/pgsql-bugs/2011-07/msg00059.php
  
 Mingw-w64 uses the same header files for 32 and 64 bit compiles. So the same 
 conditions apply to mingw-w32 bit as for the WIN64 case. In WIN64 WSAAPI is 
 defined to nothing, but in 32 bit to stdcall, so it needs to be used in the 
 accept-parameter check, too. Maybe you prefer PASCAL instead of WSAAPI in 
 configure.
  
 I tested successful compilation for the following platforms:
 - i686-w64-mingw32 - gcc v4.6.1
 - x86_64-w64-mingw32 - gcc v4.6.1
 - i586-mingw32msvc - gcc v4.4.4
 - x86_64-linux-gnu - gcc v4.6.1
  
 -- 
 Kind regards,
 Lars Kanis
  
 fix-mingw-w64-32bit_v1.patch
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers


-- 
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] [PATCH] PostgreSQL fails to build with 32bit MinGW-w64

2011-11-24 Thread NISHIYAMA Tomoaki
Hi,

 The way to build natively with a mingw-w64 compiler is doumented fairly 
 simply at 
 http://www.postgresql.org/docs/current/static/installation-platform-notes.html#INSTALLATION-NOTES-MINGW:
 
   To build 64 bit binaries using MinGW, install the 64 bit tool set
   from http://mingw-w64.sourceforge.net/, put its bin directory in the
   PATH, and run configure with the --host=x86_64-w64-mingw option. 
 
 This is exactly how the buildfarm member pitta was set up.
 
 The only issue here is how to add support for using the 32bit mingw-w64 
 compiler in pretty much the same way.


I hope that configure --host=i686-w64-mingw use 32 bit tool sets and 
construct a 32 bit binary.  It is mostly the same procedure and should have
sufficient information to distinguish them.  Both 64 bit and 32 bit binaries
should be runnable on the same 64 bit system.

Best regards,


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers