Building libpq/psql with Borland BCC5
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.
*Note: psql compiles with bcc after the patch, but it does not run very well.
Attachments:
pg821-bcc.patchtext/plain; charset=us-asciiDownload
diff -c -r src.orig/bin/psql/bcc32.mak src/bin/psql/bcc32.mak
*** src.orig/bin/psql/bcc32.mak Tue Nov 21 18:26:47 2006
--- src/bin/psql/bcc32.mak Tue Jan 9 12:17:48 2007
***************
*** 60,66 ****
!endif
REFDOCDIR=../../../doc/src/sgml/ref
! CPP_PROJ = -I$(BCB)\include;..\..\include;..\..\interfaces\libpq;..\..\include\port\win32 \
-c -D$(USERDEFINES) -DFRONTEND -n"$(INTDIR)" -tWM -tWC -q -5 -a8 -pc -X -w-use \
-w-par -w-pia -w-csu -w-aus -w-ccc
--- 60,66 ----
!endif
REFDOCDIR=../../../doc/src/sgml/ref
! CPP_PROJ = -I$(BCB)\include;..\..\include;..\..\interfaces\libpq;..\..\include\port\win32;..\..\include\port\win32_msvc;..\pg_dump;..\..\backend \
-c -D$(USERDEFINES) -DFRONTEND -n"$(INTDIR)" -tWM -tWC -q -5 -a8 -pc -X -w-use \
-w-par -w-pia -w-csu -w-aus -w-ccc
***************
*** 98,103 ****
--- 98,104 ----
-@erase "$(INTDIR)\mbprint.obj"
-@erase "$(INTDIR)\print.obj"
-@erase "$(INTDIR)\prompt.obj"
+ -@erase "$(INTDIR)\psqlscan.obj"
-@erase "$(INTDIR)\startup.obj"
-@erase "$(INTDIR)\stringutils.obj"
-@erase "$(INTDIR)\tab-complete.obj"
***************
*** 105,113 ****
--- 106,118 ----
-@erase "$(INTDIR)\exec.obj"
-@erase "$(INTDIR)\getopt.obj"
-@erase "$(INTDIR)\getopt_long.obj"
+ -@erase "$(INTDIR)\snprintf.obj"
-@erase "$(INTDIR)\path.obj"
+ -@erase "$(INTDIR)\strlcpy.obj"
-@erase "$(INTDIR)\pgstrcasecmp.obj"
-@erase "$(INTDIR)\sprompt.obj"
+ -@erase "$(INTDIR)\dumputils.obj"
+ -@erase "$(INTDIR)\keywords.obj"
-@erase "$(INTDIR)\psql.ilc"
-@erase "$(INTDIR)\psql.ild"
-@erase "$(INTDIR)\psql.tds"
***************
*** 138,146 ****
"$(INTDIR)\exec.obj" \
"$(INTDIR)\getopt.obj" \
"$(INTDIR)\getopt_long.obj" \
"$(INTDIR)\path.obj" \
"$(INTDIR)\pgstrcasecmp.obj" \
! "$(INTDIR)\sprompt.obj"
!IFDEF DEBUG
LINK32_OBJS = $(LINK32_OBJS) "..\..\interfaces\libpq\Debug\blibpqddll.lib"
--- 143,155 ----
"$(INTDIR)\exec.obj" \
"$(INTDIR)\getopt.obj" \
"$(INTDIR)\getopt_long.obj" \
+ "$(INTDIR)\snprintf.obj" \
"$(INTDIR)\path.obj" \
+ "$(INTDIR)\strlcpy.obj" \
"$(INTDIR)\pgstrcasecmp.obj" \
! "$(INTDIR)\sprompt.obj" \
! "$(INTDIR)\dumputils.obj" \
! "$(INTDIR)\keywords.obj"
!IFDEF DEBUG
LINK32_OBJS = $(LINK32_OBJS) "..\..\interfaces\libpq\Debug\blibpqddll.lib"
***************
*** 149,155 ****
!ENDIF
# Have to use \# so # isn't treated as a comment, but MSVC doesn't like this
! "..\..\port\pg_config_paths.h": win32.mak
echo \#define PGBINDIR "" >$@
echo \#define PGSHAREDIR "" >>$@
echo \#define SYSCONFDIR "" >>$@
--- 158,164 ----
!ENDIF
# Have to use \# so # isn't treated as a comment, but MSVC doesn't like this
! "..\..\port\pg_config_paths.h": bcc32.mak
echo \#define PGBINDIR "" >$@
echo \#define PGSHAREDIR "" >>$@
echo \#define SYSCONFDIR "" >>$@
***************
*** 188,198 ****
--- 197,217 ----
$(CPP_PROJ) ..\..\port\getopt_long.c
<<
+ "$(INTDIR)\snprintf.obj" : "$(INTDIR)" ..\..\port\snprintf.c
+ $(CPP) @<<
+ $(CPP_PROJ) ..\..\port\snprintf.c
+ <<
+
"$(INTDIR)\path.obj" : "$(INTDIR)" ..\..\port\path.c
$(CPP) @<<
$(CPP_PROJ) ..\..\port\path.c
<<
+ "$(INTDIR)\strlcpy.obj" : "$(INTDIR)" ..\..\port\strlcpy.c
+ $(CPP) @<<
+ $(CPP_PROJ) ..\..\port\strlcpy.c
+ <<
+
"$(INTDIR)\pgstrcasecmp.obj" : ..\..\port\pgstrcasecmp.c
$(CPP) @<<
$(CPP_PROJ) ..\..\port\pgstrcasecmp.c
***************
*** 203,208 ****
--- 222,237 ----
$(CPP_PROJ) ..\..\port\sprompt.c
<<
+ "$(INTDIR)\dumputils.obj" : "$(INTDIR)" ..\pg_dump\dumputils.c
+ $(CPP) @<<
+ $(CPP_PROJ) ..\pg_dump\dumputils.c
+ <<
+
+ "$(INTDIR)\keywords.obj" : "$(INTDIR)" ..\..\backend\parser\keywords.c
+ $(CPP) @<<
+ $(CPP_PROJ) ..\..\backend\parser\keywords.c
+ <<
+
"sql_help.h": create_help.pl
$(PERL) create_help.pl $(REFDOCDIR) $@
diff -c -r src.orig/include/c.h src/include/c.h
*** src.orig/include/c.h Tue Oct 3 20:30:06 2006
--- src/include/c.h Tue Jan 9 12:18:57 2007
***************
*** 59,65 ****
#include "postgres_ext.h"
#include "pg_trace.h"
! #if defined(__BORLANDC__) || (_MSC_VER >= 1400)
#define errcode __msvc_errcode
#include <crtdefs.h>
#undef errcode
--- 59,65 ----
#include "postgres_ext.h"
#include "pg_trace.h"
! #if _MSC_VER >= 1400
#define errcode __msvc_errcode
#include <crtdefs.h>
#undef errcode
diff -c -r src.orig/include/port/win32.h src/include/port/win32.h
*** src.orig/include/port/win32.h Thu Oct 19 16:03:08 2006
--- src/include/port/win32.h Tue Jan 9 13:03:48 2007
***************
*** 17,23 ****
--- 17,25 ----
#include <signal.h>
#include <errno.h>
#include <direct.h>
+ #ifndef __BORLANDC__
#include <sys/utime.h> /* for non-unicode version */
+ #endif
#undef near
/* Must be here to avoid conflicting with prototype in windows.h */
***************
*** 149,156 ****
--- 151,160 ----
#define SIGTTIN 21
#define SIGTTOU 22 /* Same as SIGABRT -- no problem, I hope */
#define SIGWINCH 28
+ #ifndef __BORLANDC__
#define SIGUSR1 30
#define SIGUSR2 31
+ #endif
struct timezone
{
***************
*** 259,266 ****
--- 263,272 ----
/* Things that exist in MingW headers, but need to be added to MSVC */
#ifdef WIN32_ONLY_COMPILER
+ #ifndef __BORLANDC__
typedef long ssize_t;
typedef unsigned short mode_t;
+ #endif
/*
* Certain "standard edition" versions of MSVC throw a warning
***************
*** 271,276 ****
--- 277,283 ----
#define inline __inline
#define __inline__ __inline
+ #ifndef __BORLANDC__
#define _S_IRWXU (_S_IREAD | _S_IWRITE | _S_IEXEC)
#define _S_IXUSR _S_IEXEC
#define _S_IWUSR _S_IWRITE
***************
*** 280,285 ****
--- 287,293 ----
#define S_IXUSR _S_IXUSR
#define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
+ #endif
#define F_OK 0
#define W_OK 2
diff -c -r src.orig/include/port.h src/include/port.h
*** src.orig/include/port.h Mon Nov 27 20:12:33 2006
--- src/include/port.h Tue Jan 9 12:19:52 2007
***************
*** 343,349 ****
extern size_t strlcpy(char *dst, const char *src, size_t siz);
#endif
! #ifndef HAVE_RANDOM
extern long random(void);
#endif
--- 343,349 ----
extern size_t strlcpy(char *dst, const char *src, size_t siz);
#endif
! #if !defined(HAVE_RANDOM) && !defined(__BORLANDC__)
extern long random(void);
#endif
diff -c -r src.orig/interfaces/libpq/bcc32.mak src/interfaces/libpq/bcc32.mak
*** src.orig/interfaces/libpq/bcc32.mak Tue Nov 21 18:26:47 2006
--- src/interfaces/libpq/bcc32.mak Tue Jan 9 13:05:06 2007
***************
*** 76,82 ****
CLEAN :
-@erase "$(INTDIR)\getaddrinfo.obj"
-@erase "$(INTDIR)\pgstrcasecmp.obj"
- -@erase "$(INTDIR)\strlcpy.obj"
-@erase "$(INTDIR)\thread.obj"
-@erase "$(INTDIR)\inet_aton.obj"
-@erase "$(INTDIR)\crypt.obj"
--- 76,81 ----
***************
*** 99,104 ****
--- 98,105 ----
-@erase "$(INTDIR)\wchar.obj"
-@erase "$(INTDIR)\encnames.obj"
-@erase "$(INTDIR)\pthread-win32.obj"
+ -@erase "$(INTDIR)\snprintf.obj"
+ -@erase "$(INTDIR)\strlcpy.obj"
-@erase "$(OUTDIR)\$(OUTFILENAME).lib"
-@erase "$(OUTDIR)\$(OUTFILENAME)dll.lib"
-@erase "$(OUTDIR)\libpq.res"
***************
*** 113,119 ****
"$(INTDIR)\win32.obj" \
"$(INTDIR)\getaddrinfo.obj" \
"$(INTDIR)\pgstrcasecmp.obj" \
- "$(INTDIR)\strlcpy.obj" \
"$(INTDIR)\thread.obj" \
"$(INTDIR)\inet_aton.obj" \
"$(INTDIR)\crypt.obj" \
--- 114,119 ----
***************
*** 133,138 ****
--- 133,140 ----
"$(INTDIR)\pqsignal.obj" \
"$(INTDIR)\wchar.obj" \
"$(INTDIR)\encnames.obj" \
+ "$(INTDIR)\snprintf.obj" \
+ "$(INTDIR)\strlcpy.obj" \
"$(INTDIR)\pthread-win32.obj"
***************
*** 162,168 ****
$(LINK32_FLAGS) +
c0d32.obj $(LINK32_OBJS), +
$@,, +
! "$(OUTDIR)\blibpq.lib" import32.lib cw32mti.lib, +
blibpqdll.def,"$(INTDIR)\libpq.res"
<<
implib -w "$(OUTDIR)\blibpqdll.lib" blibpqdll.def $@
--- 164,170 ----
$(LINK32_FLAGS) +
c0d32.obj $(LINK32_OBJS), +
$@,, +
! "$(OUTDIR)\blibpq.lib" import32.lib cw32mt.lib, +
blibpqdll.def,"$(INTDIR)\libpq.res"
<<
implib -w "$(OUTDIR)\blibpqdll.lib" blibpqdll.def $@
***************
*** 187,197 ****
$(CPP_PROJ) ..\..\port\pgstrcasecmp.c
<<
- "$(INTDIR)\strlcpy.obj" : ..\..\port\strlcpy.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\strlcpy.c
- <<
-
"$(INTDIR)\thread.obj" : ..\..\port\thread.c
$(CPP) @<<
$(CPP_PROJ) ..\..\port\thread.c
--- 189,194 ----
***************
*** 233,237 ****
--- 230,245 ----
$(CPP_PROJ) /I"." ..\..\backend\utils\mb\encnames.c
<<
+ "$(INTDIR)\snprintf.obj" : ..\..\port\snprintf.c
+ $(CPP) @<<
+ $(CPP_PROJ) /I"." ..\..\port\snprintf.c
+ <<
+
+ "$(INTDIR)\strlcpy.obj" : ..\..\port\strlcpy.c
+ $(CPP) @<<
+ $(CPP_PROJ) ..\..\port\strlcpy.c
+ <<
+
+
.c.obj:
$(CPP) $(CPP_PROJ) $<
diff -c -r src.orig/interfaces/libpq/win32.mak src/interfaces/libpq/win32.mak
*** src.orig/interfaces/libpq/win32.mak Tue Nov 21 18:26:47 2006
--- src/interfaces/libpq/win32.mak Tue Jan 9 12:25:03 2007
***************
*** 74,81 ****
-@erase "$(OUTDIR)\$(OUTFILENAME)dll.lib"
-@erase "$(OUTDIR)\libpq.res"
-@erase "$(OUTDIR)\$(OUTFILENAME).dll"
- # -@erase "*.pch"
- # -@erase "$(OUTDIR)\libpq.pch"
-@erase "$(OUTDIR)\$(OUTFILENAME)dll.exp"
-@erase "$(INTDIR)\pg_config_paths.h"
--- 74,79 ----
On Tue, 9 Jan 2007, L Bayuk wrote:
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.*Note: psql compiles with bcc after the patch, but it does not run very well.
Define "does not run very well" :-)
Gavin
Gavin Sherry wrote:
On Tue, 9 Jan 2007, L Bayuk wrote:
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.*Note: psql compiles with bcc after the patch, but it does not run very well.
Define "does not run very well" :-)
See:
http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00003.php
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Tue, 9 Jan 2007, Bruce Momjian wrote:
Gavin Sherry wrote:
On Tue, 9 Jan 2007, L Bayuk wrote:
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.*Note: psql compiles with bcc after the patch, but it does not run very well.
Define "does not run very well" :-)
See:
http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00003.php
*blinks*
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
Gavin
Gavin Sherry wrote:
On Tue, 9 Jan 2007, Bruce Momjian wrote:
Gavin Sherry wrote:
On Tue, 9 Jan 2007, L Bayuk wrote:
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.*Note: psql compiles with bcc after the patch, but it does not run very well.
Define "does not run very well" :-)
See:
http://archives.postgresql.org/pgsql-interfaces/2007-01/msg00003.php
*blinks*
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
The bcc users say it is.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Gavin Sherry <swm@linuxworld.com.au> writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...
regards, tom lane
Tom Lane wrote:
Gavin Sherry <swm@linuxworld.com.au> writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...
It does build, but the report is that psql crashes after a few commands.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote:
Tom Lane wrote:
Gavin Sherry <swm@linuxworld.com.au> writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...It does build, but the report is that psql crashes after a few commands.
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?
It would be nice to have the libpq at least able to pass the regression
tests.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Gavin Sherry <swm@linuxworld.com.au> writes:
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?Well, I'd not trust it a lot, but surely we have to get it to build
before anyone can debug it ...It does build, but the report is that psql crashes after a few commands.
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?
No idea.
It would be nice to have the libpq at least able to pass the regression
tests.
True.
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On 1/10/07, Alvaro Herrera <alvherre@commandprompt.com> wrote:
What about a Mingw or VC++ psql with a BCC libpq? Is it possible to
link something like that?It would be nice to have the libpq at least able to pass the regression
tests.
you can use microsoft/mingw compiled DLL files but not library files.
however, borland provides a command line tool (implib i thnk) to
create an import library for it which works ok. (i think you have to
pass a switch to fix underscore issue).
libpq.lib is not directly usable (coff vs. omf) but digital mars makes
a tool which can do this and I have confirmed it works.
note: I've used borland compiled libpq (not psql) with borland C++
builder 3 & 5 with no problems. I had to hack pg_config.h however.
merlin
Patch applied. Thanks.
Backpatch to 8.2.X.z
---------------------------------------------------------------------------
L Bayuk wrote:
The attached patch against PostgreSQL-8.2.1 was discussed on [INTERFACES].
It fixes bcc32.mak makefiles for the Borland BCC compiler to build libpq
and psql*. There are also changes to some header files to hide some things
BCC doesn't like.*Note: psql compiles with bcc after the patch, but it does not run very well.
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Wed, Jan 10, 2007 at 02:53:01PM +1100, Gavin Sherry wrote:
...
Can we be sure that a BCC build libpq is even safe to use given the
problems seen when using psql?
I have high confidence in my BCC-built libpq, in so far as its functions
are exposed through the Tcl interface pgtcl-ng. My test suite for pgtcl
is rather thorough (more below), and it passes using BCC-built libpq.
Compare that to the fact that my BCC-built psql crashes consistently after
six "\h set" commands - which don't even use libpq! - and you can see why I
think the problem is entirely in psql.
BCC was free to use and easy to set up, and I was able to make Tcl-loadable
modules with it, so that's what I'm using for pgtcl-ng. I'm not suggesting
people use it for anything else based on what I've done. If there is a
regression test for libpq which does not use psql, show me and I'll run it.
Otherwise, people will have to do their own testing. But in my opinion if
you have Mingw or VC++, use it (not that I've used either).
.....
My test suite exercises libpq/pgtcl. I use it for pgtclng and pgintcl (see
pgfoundry). It runs about 160 test cases on Windows (more on Linux, where
it tests for memory leaks, but I don't know how to do that on Windows). It
includes: synchronous and asynchronous queries, extended 8-bit characters,
COPY From/To, cursors with text and binary data, error detection, prepared
and parameterized queries (text and binary data), large objects, long TEXT
fields, 300-column table queries, transactions, and more. I have some
performance tests in there as a sanity check, including my favorite: a
single query against a 1-column 10-row table which takes 3-10 minutes of
backend time.
Three tests claim to fail on Windows, same as always. Changes to
environment variables like PGUSER within the script are not seen by
pg_connect; this is apparently a DLL thing. The other 2 failures are
false, and have to do with a limitation of tcltest not seeing output
notification messages written by libpq. These are not real errors.