test/example does not support win32.
Hi.
test/example does not support win32.
Although I posted also in the past, I am slightly persistent.
I think whether it also needs correction of a document.
== CVS-HEAD on as for MinGW + gcc ==
testlibpq2.c: In function `main':
testlibpq2.c:98: error: `fd_set' undeclared (first use in this function)
testlibpq2.c:98: error: (Each undeclared identifier is reported only once
testlibpq2.c:98: error: for each function it appears in.)
testlibpq2.c:98: error: syntax error before "input_mask"
testlibpq2.c:105: warning: implicit declaration of function `FD_ZERO'
testlibpq2.c:105: error: `input_mask' undeclared (first use in this function)
testlibpq2.c:106: warning: implicit declaration of function `FD_SET'
testlibpq2.c:108: warning: implicit declaration of function `select'
make: *** [testlibpq2] Error 1
testlibpq3.c: In function `show_binary_results':
testlibpq3.c:82: error: `uint32_t' undeclared (first use in this function)
testlibpq3.c:82: error: (Each undeclared identifier is reported only once
testlibpq3.c:82: error: for each function it appears in.)
testlibpq3.c:82: error: syntax error before ')' token
testlibpq3.c: In function `main':
testlibpq3.c:115: error: `uint32_t' undeclared (first use in this function)
testlibpq3.c:115: error: syntax error before "binaryIntVal"
testlibpq3.c:183: error: `binaryIntVal' undeclared (first use in this function)
testlibpq3.c:183: error: syntax error before numeric constant
make: *** [testlibpq3] Error 1
Please take into consideration.
Regards,
Hiroshi Saito
Attachments:
examples_win32_patchapplication/octet-stream; name=examples_win32_patchDownload
*** src/test/examples/Makefile.orig Wed Dec 30 13:30:13 2009
--- src/test/examples/Makefile Wed Dec 30 13:30:46 2009
***************
*** 6,11 ****
--- 6,15 ----
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
+ ifeq ($(PORTNAME), win32)
+ LDLIBS += -lws2_32
+ endif
+
override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
override LDLIBS := $(libpq_pgport) $(LDLIBS)
*** src/test/examples/testlibpq2.c.orig Wed Dec 30 13:19:03 2009
--- src/test/examples/testlibpq2.c Wed Dec 30 13:28:56 2009
***************
*** 24,29 ****
--- 24,32 ----
*
* INSERT INTO TBL1 VALUES (10);
*/
+
+ #include "postgres_fe.h"
+
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
*** src/test/examples/testlibpq3.c.orig Wed Dec 30 13:31:41 2009
--- src/test/examples/testlibpq3.c Wed Dec 30 13:37:35 2009
***************
*** 25,35 ****
--- 25,42 ----
* t = (8 bytes) 'ho there'
* b = (5 bytes) \004\003\002\001\000
*/
+
+ #include "postgres_fe.h"
+
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include "libpq-fe.h"
+
+ #if defined(WIN32)
+ #include <stdint.h>
+ #endif
/* for ntohl/htonl */
#include <netinet/in.h>
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
test/example does not support win32.
The proposed added #includes seem quite inappropriate. postgres_fe.h
is meant for PG-project code, it is not supposed to have to be included
by all end-user code.
regards, tom lane
Hi Tom-san.
Um, How do you consider sample which cannot build?
Regards,
Hiroshi Saito
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Show quoted text
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
test/example does not support win32.
The proposed added #includes seem quite inappropriate. postgres_fe.h
is meant for PG-project code, it is not supposed to have to be included
by all end-user code.regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hiroshi Saito wrote:
Hi Tom-san.
Um, How do you consider sample which cannot build?
I think testlibpq2.c is missing a couple of system includes, sys/types.h
and unistd.h (or alternatively select.h); and testlibpq3.c is missing
stdint.h. Or so say my (POSIX) manpages anyway.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hi Alvaro-san.
Yes, I thinks that it is an exact idea. However, this example was not helped.
fd_set complains....
Thanks!
It seems that pg_bench takes the thing same again into consideration.
Anyway, If it is called example of end-user code, what is the evasion method
of fd_set?
Regards,
Hiroshi Saito
----- Original Message -----
From: "Alvaro Herrera" <alvherre@commandprompt.com>
Show quoted text
Hiroshi Saito wrote:
Hi Tom-san.
Um, How do you consider sample which cannot build?
I think testlibpq2.c is missing a couple of system includes, sys/types.h
and unistd.h (or alternatively select.h); and testlibpq3.c is missing
stdint.h. Or so say my (POSIX) manpages anyway.--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
Yes, I thinks that it is an exact idea. However, this example was not helped.
fd_set complains....
Thanks!
It seems that pg_bench takes the thing same again into consideration.
Anyway, If it is called example of end-user code, what is the evasion method
of fd_set?
On reflection I think it's just wrong to expect that the examples will
compile out-of-the-box on every platform. The only way that that can
possibly happen is if they depend on our configuration infrastructure,
which is exactly what I feel they should not depend on. Any client
program that has ambitions of portability is going to have its own
autoconf stuff, so injecting ours into a piece of sample code is just
going to result in headaches. Even including only pg_config.h would
be a serious invasion of application namespace.
Looking at pgbench, or any other one of our client-side programs,
is not relevant to the point here. Those programs *are* supposed
to rely on the PG autoconf environment.
We can certainly add some more standard #includes to the examples
if they're obviously missing some. But that isn't going to get us
to a point where they'll compile everywhere without change.
regards, tom lane
Tom Lane wrote:
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
Yes, I thinks that it is an exact idea. However, this example was not helped.
fd_set complains....
Thanks!It seems that pg_bench takes the thing same again into consideration.
Anyway, If it is called example of end-user code, what is the evasion method
of fd_set?On reflection I think it's just wrong to expect that the examples will
compile out-of-the-box on every platform. The only way that that can
possibly happen is if they depend on our configuration infrastructure,
which is exactly what I feel they should not depend on. Any client
program that has ambitions of portability is going to have its own
autoconf stuff, so injecting ours into a piece of sample code is just
going to result in headaches. Even including only pg_config.h would
be a serious invasion of application namespace.Looking at pgbench, or any other one of our client-side programs,
is not relevant to the point here. Those programs *are* supposed
to rely on the PG autoconf environment.We can certainly add some more standard #includes to the examples
if they're obviously missing some. But that isn't going to get us
to a point where they'll compile everywhere without change.
Well, those example programs are pretty clean libpq apps so I don't see
why they should using platform-specific stuff.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
Well, those example programs are pretty clean libpq apps so I don't see
why they should using platform-specific stuff.
Example #2 depends on select(), which depends on fd_set, so you're
already into territory where there are issues.
regards, tom lane
Tom Lane wrote:
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
Yes, I thinks that it is an exact idea. However, this example was not helped.
fd_set complains....
Thanks!It seems that pg_bench takes the thing same again into consideration.
Anyway, If it is called example of end-user code, what is the evasion method
of fd_set?On reflection I think it's just wrong to expect that the examples will
compile out-of-the-box on every platform. The only way that that can
possibly happen is if they depend on our configuration infrastructure,
which is exactly what I feel they should not depend on. Any client
program that has ambitions of portability is going to have its own
autoconf stuff, so injecting ours into a piece of sample code is just
going to result in headaches. Even including only pg_config.h would
be a serious invasion of application namespace.Looking at pgbench, or any other one of our client-side programs,
is not relevant to the point here. Those programs *are* supposed
to rely on the PG autoconf environment.We can certainly add some more standard #includes to the examples
if they're obviously missing some. But that isn't going to get us
to a point where they'll compile everywhere without change.
That would be all good and well if we didn't already rely on the
configure setup. But we do - the Makefile includes src/Makefile.global,
which is built by configure.
Anyway, let's see how far we can get with including some standard header
files.
cheers
andrew
Hi Andrew-san.
Although this is a standard in windows.
*** testlibpq2.c.orig Wed Dec 30 13:19:03 2009
--- testlibpq2.c Thu Dec 31 00:52:52 2009
***************
*** 24,34 ****
--- 24,39 ----
*
* INSERT INTO TBL1 VALUES (10);
*/
+
+ #ifdef WIN32
+ #include <windows.h>
+ #endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/time.h>
+ #include <sys/types.h>
#include "libpq-fe.h"static void
Does this become the standard which you consider?
or #IFDEF Isn't it allowed?
Regards,
Hiroshi Saito
----- Original Message -----
From: "Andrew Dunstan" <andrew@dunslane.net>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>; "Alvaro Herrera"
<alvherre@commandprompt.com>; "pgsql-hackers" <pgsql-hackers@postgresql.org>; "Bruce
Momjian" <bruce@momjian.us>
Sent: Thursday, December 31, 2009 12:45 AM
Subject: Re: [HACKERS] test/example does not support win32.
Show quoted text
Tom Lane wrote:
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set
complains.... Thanks!It seems that pg_bench takes the thing same again into consideration. Anyway, If it is
called example of end-user code, what is the evasion method
of fd_set?On reflection I think it's just wrong to expect that the examples will
compile out-of-the-box on every platform. The only way that that can
possibly happen is if they depend on our configuration infrastructure,
which is exactly what I feel they should not depend on. Any client
program that has ambitions of portability is going to have its own
autoconf stuff, so injecting ours into a piece of sample code is just
going to result in headaches. Even including only pg_config.h would
be a serious invasion of application namespace.Looking at pgbench, or any other one of our client-side programs,
is not relevant to the point here. Those programs *are* supposed
to rely on the PG autoconf environment.We can certainly add some more standard #includes to the examples
if they're obviously missing some. But that isn't going to get us
to a point where they'll compile everywhere without change.That would be all good and well if we didn't already rely on the configure setup. But we
do - the Makefile includes src/Makefile.global, which is built by configure.Anyway, let's see how far we can get with including some standard header files.
cheers
andrew
Hiroshi Saito wrote:
Hi Andrew-san.
Although this is a standard in windows.
*** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 --- testlibpq2.c Thu Dec 31 00:52:52 2009 *************** *** 24,34 **** --- 24,39 ---- * * INSERT INTO TBL1 VALUES (10); */ + + #ifdef WIN32 + #include <windows.h> + #endif #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <sys/time.h> + #include <sys/types.h> #include "libpq-fe.h"static void
Does this become the standard which you consider?
or #IFDEF Isn't it allowed?
I certainly think we can use ifdefs. This addition seems OK to me at
first glance. Does it solve the problem you encountered?
cheers
andrew
Andrew Dunstan <andrew@dunslane.net> writes:
Tom Lane wrote:
On reflection I think it's just wrong to expect that the examples will
compile out-of-the-box on every platform.
That would be all good and well if we didn't already rely on the
configure setup. But we do - the Makefile includes src/Makefile.global,
which is built by configure.
That makefile is not part of the examples. It wouldn't get copied and
pasted into someone's source code.
Anyway, let's see how far we can get with including some standard header
files.
Sure, no objection to that. It's when somebody starts wanting to use
HAVE_FOO symbols that I get unhappy.
regards, tom lane
Hi Andrew-san.
This saves a windows users.
I appreciate your suggestion.
Thanks!
P.S)
I often use by the test by nmake at the time of independent creation of libpq.
Regards,
Hiroshi Saito
----- Original Message -----
From: "Andrew Dunstan" <andrew@dunslane.net>
Show quoted text
Hiroshi Saito wrote:
Hi Andrew-san.
Although this is a standard in windows.
*** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 --- testlibpq2.c Thu Dec 31 00:52:52 2009 *************** *** 24,34 **** --- 24,39 ---- * * INSERT INTO TBL1 VALUES (10); */ + + #ifdef WIN32 + #include <windows.h> + #endif #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <sys/time.h> + #include <sys/types.h> #include "libpq-fe.h"static void
Does this become the standard which you consider?
or #IFDEF Isn't it allowed?I certainly think we can use ifdefs. This addition seems OK to me at
first glance. Does it solve the problem you encountered?cheers
andrew
Attachments:
examples_win32_patch2application/octet-stream; name=examples_win32_patch2Download
*** src/test/examples/Makefile.orig Wed Dec 30 13:30:13 2009
--- src/test/examples/Makefile Thu Dec 31 00:08:39 2009
***************
*** 6,13 ****
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
! override LDLIBS := $(libpq_pgport) $(LDLIBS)
PROGS = testlibpq testlibpq2 testlibpq3 testlibpq4 testlo
--- 6,17 ----
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
+ ifeq ($(PORTNAME), win32)
+ LDLIBS += -lws2_32
+ endif
+
override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
! override LDLIBS := $(libpq_pgport) $(LDLIBS) -DFRONTEND
PROGS = testlibpq testlibpq2 testlibpq3 testlibpq4 testlo
*** src/test/examples/testlibpq2.c.orig Wed Dec 30 13:19:03 2009
--- src/test/examples/testlibpq2.c Thu Dec 31 00:52:52 2009
***************
*** 24,34 ****
--- 24,39 ----
*
* INSERT INTO TBL1 VALUES (10);
*/
+
+ #ifdef WIN32
+ #include <windows.h>
+ #endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/time.h>
+ #include <sys/types.h>
#include "libpq-fe.h"
static void
*** src/test/examples/testlibpq3.c.orig Thu Dec 31 01:14:54 2009
--- src/test/examples/testlibpq3.c Thu Dec 31 01:12:20 2009
***************
*** 25,32 ****
--- 25,38 ----
* t = (8 bytes) 'ho there'
* b = (5 bytes) \004\003\002\001\000
*/
+
+ #ifdef WIN32
+ #include <windows.h>
+ #endif
+
#include <stdio.h>
#include <stdlib.h>
+ #include <stdint.h>
#include <string.h>
#include <sys/types.h>
#include "libpq-fe.h"
2009/12/30 Hiroshi Saito <z-saito@guitar.ocn.ne.jp>:
Hi Andrew-san.
This saves a windows users.
I appreciate your suggestion.
Thanks!
This one looks much better. +1 for this version :-)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
[ examples_win32_patch2 ]
Is the addition of -DFRONTEND actually needed, and if so why?
We shouldn't be depending on that in any user-exposed code, I would
think. Otherwise I don't have any objection to this version.
regards, tom lane
Hi Tom-san.
Ahh.. It was correction of the test of often...
again, the pursued relation was seen, I think that it is good now.
Thanks!!
Regards,
Hiroshi Saito
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Show quoted text
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
[ examples_win32_patch2 ]
Is the addition of -DFRONTEND actually needed, and if so why?
We shouldn't be depending on that in any user-exposed code, I would
think. Otherwise I don't have any objection to this version.regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Attachments:
examples_win32_patch3application/octet-stream; name=examples_win32_patch3Download
*** src/test/examples/Makefile.orig Wed Dec 30 13:30:13 2009
--- src/test/examples/Makefile Thu Dec 31 01:42:07 2009
***************
*** 6,11 ****
--- 6,15 ----
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global
+ ifeq ($(PORTNAME), win32)
+ LDLIBS += -lws2_32
+ endif
+
override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS)
override LDLIBS := $(libpq_pgport) $(LDLIBS)
*** src/test/examples/testlibpq2.c.orig Wed Dec 30 13:19:03 2009
--- src/test/examples/testlibpq2.c Thu Dec 31 00:52:52 2009
***************
*** 24,34 ****
--- 24,39 ----
*
* INSERT INTO TBL1 VALUES (10);
*/
+
+ #ifdef WIN32
+ #include <windows.h>
+ #endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/time.h>
+ #include <sys/types.h>
#include "libpq-fe.h"
static void
*** src/test/examples/testlibpq3.c.orig Thu Dec 31 01:14:54 2009
--- src/test/examples/testlibpq3.c Thu Dec 31 01:12:20 2009
***************
*** 25,32 ****
--- 25,38 ----
* t = (8 bytes) 'ho there'
* b = (5 bytes) \004\003\002\001\000
*/
+
+ #ifdef WIN32
+ #include <windows.h>
+ #endif
+
#include <stdio.h>
#include <stdlib.h>
+ #include <stdint.h>
#include <string.h>
#include <sys/types.h>
#include "libpq-fe.h"