src/interfaces/libpq shipping nmake-related Makefiles
Hi all,
While looking at some SCRAM stuff, I have bumped into bcc32.mak and
win32.mak in src/interfaces/libpq. To put it short: those files are
not up to date. The code of SCRAM is in the tree for a bit of time
now, and should have updated those files to list and clean up objects,
but nobody has reported failures in using them.
At the minimum, they should be updated. Or perhaps they could just be
ripped out? Who uses that on Windows now?
Thanks,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
While looking at some SCRAM stuff, I have bumped into bcc32.mak and
win32.mak in src/interfaces/libpq. To put it short: those files are
not up to date. The code of SCRAM is in the tree for a bit of time
now, and should have updated those files to list and clean up objects,
but nobody has reported failures in using them.
At the minimum, they should be updated. Or perhaps they could just be
ripped out? Who uses that on Windows now?
I'm quite sure no developers use them, or have done so for years.
The ostensible point is to support people who are trying to build
just libpq on Windows, for use in applications talking to PG servers
elsewhere. It was reasonable that some users would want to
do that back when we didn't have a credible native port of the server,
but it's been quite some time since that was true.
In short, I think we could rip them out without much push-back.
But maybe I'm missing some remaining use-case.
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
I wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
While looking at some SCRAM stuff, I have bumped into bcc32.mak and
win32.mak in src/interfaces/libpq. To put it short: those files are
not up to date. The code of SCRAM is in the tree for a bit of time
now, and should have updated those files to list and clean up objects,
but nobody has reported failures in using them.
At the minimum, they should be updated. Or perhaps they could just be
ripped out? Who uses that on Windows now?
I'm quite sure no developers use them, or have done so for years.
A bit of digging in the git logs says that the last patch that clearly
resulted from user interest in Borland C was ce53791b2 in April 2009.
bcc32.mak has been touched in passing for various other changes since
then, but I'd say the odds that it actually still works are pretty small,
even before this issue.
win32.mak has considerably more recent interest, eg cd9b4f24c.
So we should consider the two cases separately.
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter. The core argument for bcc32.mak,
I think, is that we never did support building the server with Borland C
... but there's no evidence that people are still building libpq with it
either.
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
On 2017-04-07 00:01:01 -0400, Tom Lane wrote:
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter.
I think the raison d'etre for that infrastructure primarily comes from
the times where windows wasn't supported for server builds?
+1 for yanking this out.
- Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter. The core argument for bcc32.mak,
I think, is that we never did support building the server with Borland C
... but there's no evidence that people are still building libpq with it
either.
Indeed. Those recent reports indicate that removing win32.c would be a
bad move. So what about nuking bcc32.mak but updating win32.mak?
--
Michael
VMware vCenter Server
www.vmware.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter. The core argument for bcc32.mak,
I think, is that we never did support building the server with Borland C
... but there's no evidence that people are still building libpq with it
either.Indeed. Those recent reports indicate that removing win32.c would be a
bad move.
For me they indicate the contrary, that we're currently not properly
maintaining it so that longstanding errors crop up.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter.
Indeed. Those recent reports indicate that removing win32.c would be a
bad move.
For me they indicate the contrary, that we're currently not properly
maintaining it so that longstanding errors crop up.
Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with win32.mak. Given our
lack of infrastructure for testing win32.mak, continuing support for it
seems like quite an expensive proposition from the developer-time
standpoint. I don't really want to do that if it's only going to save
somebody an occasional few minutes of build time.
bcc32.mak is in a different category because it's basically the only
solution if you want to build libpq in Borland C. But the lack of
user input suggests that maybe nobody cares about that anymore.
Borland C, per se, has been dead since the 90s according to wikipedia.
There are successor products with different names, none of which I can
recall anybody ever mentioning on the PG lists. I speculate that
people are taking libpq.dll built with MSVC and using it in those
products, if they're using them with PG at all.
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
On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andres Freund <andres@anarazel.de> writes:
On 2017-04-07 13:07:59 +0900, Michael Paquier wrote:
On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Still, it's not very clear why we need to cater for building just libpq
rather than the whole distribution, and a user of win32.mak presumably
has the option to do the latter.Indeed. Those recent reports indicate that removing win32.c would be a
bad move.For me they indicate the contrary, that we're currently not properly
maintaining it so that longstanding errors crop up.
Is it broken in HEAD only or also in 9.6?
I think whomever uses win32.mak to build is quite unlikely to be tracking
HEAD. They would notice at release time. (Since we don't have a buildfarm
animal doing it)
Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with win32.mak. Given our
lack of infrastructure for testing win32.mak, continuing support for it
seems like quite an expensive proposition from the developer-time
standpoint. I don't really want to do that if it's only going to save
somebody an occasional few minutes of build time.
Insurmountable, probably not. The big difference is that you don't need
*any* dependencies to build a libpq using win32.mak, but you need many of
them (to start with, perl...) to build using the built-in one. For people
who want to build it, it certainly save a lot more than "a few minutes".
For somebody who doesn't have ready scripts it takes a *long* time to set
up a build environment to do our regular msvc builds.
I think the question is more, is there any need for people to do that at
all, or are those people just going to be using the pre-built binaries
anyway? That question I can't say I know the answer to.
bcc32.mak is in a different category because it's basically the only
solution if you want to build libpq in Borland C. But the lack of
user input suggests that maybe nobody cares about that anymore.
I think there's always been even fewer users of bcc32.mak than of the
win32.mak one.
Borland C, per se, has been dead since the 90s according to wikipedia.
There are successor products with different names, none of which I can
recall anybody ever mentioning on the PG lists. I speculate that
people are taking libpq.dll built with MSVC and using it in those
products, if they're using them with PG at all.
The compiler is still called bcc (bcc32c to be specific - see
https://www.embarcadero.com/free-tools/ccompiler). Apparently it's clang
based now. I don't know if our mak file even works with that anymore
though, it wouldn't surprise me if it doesn't. But the non-change-of-name
could be why we're not seeing questions about it.
FWIW, I've suggested we drop it before, so no objections to that part from
me (and if we do, there's some #ifdefs around it in headers as well).
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 04/07/2017 02:00 PM, Magnus Hagander wrote:
On Fri, Apr 7, 2017 at 6:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah. For win32.mak, the key question is whether there is still anybody
who'd have an insurmountable problem with building the whole distro via
src/tools/msvc/ rather than just building libpq with win32.mak. Given our
lack of infrastructure for testing win32.mak, continuing support for it
seems like quite an expensive proposition from the developer-time
standpoint. I don't really want to do that if it's only going to save
somebody an occasional few minutes of build time.Insurmountable, probably not. The big difference is that you don't need
*any* dependencies to build a libpq using win32.mak, but you need many of
them (to start with, perl...) to build using the built-in one. For people
who want to build it, it certainly save a lot more than "a few minutes".
For somebody who doesn't have ready scripts it takes a *long* time to set
up a build environment to do our regular msvc builds.I think the question is more, is there any need for people to do that at
all, or are those people just going to be using the pre-built binaries
anyway? That question I can't say I know the answer to.
It does seem handy, if all you want is libpq. Clearly not many people
use it, though.
I just tested it. After adding all the missing files to the makefile,
I'm getting an error:
.\Release\libpq.dll.manifest : general error c1010070: Failed to load and parse
the manifest. The system cannot find the file specified.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows Kits\10\bin\x86\mt.
XE"' : return code '0x1f'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.
\VC\BIN\nmake.EXE"' : return code '0x2'
Stop.
This seems be the same as the 2nd error that was reported back in 2013:
/messages/by-id/CAJ2=PVQcW8UGNnSy=Ow=vUK2zpjowTkzUS1B864REa7LOT140Q@mail.gmail.com.
Despite the failure, it built a libpq.dll file, and it seems to work. I
have no idea what the manifest file is.
I could easily add the missing files to win32.mak, but unless someone
else steps up to the plate and fixes the manifest issue, I don't think
we have much choice but remove the it.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> writes:
I just tested it. After adding all the missing files to the makefile,
I'm getting an error:
.\Release\libpq.dll.manifest : general error c1010070: Failed to load and parse
the manifest. The system cannot find the file specified.
This seems be the same as the 2nd error that was reported back in 2013:
/messages/by-id/CAJ2=PVQcW8UGNnSy=Ow=vUK2zpjowTkzUS1B864REa7LOT140Q@mail.gmail.com.
Well, if it's been broken since (at least) 2013, and we've had only one
complaint, then I'd say there are too few potential users to justify
the maintenance burden.
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
On 04/07/2017 09:58 AM, Tom Lane wrote:
This seems be the same as the 2nd error that was reported back in 2013:
/messages/by-id/CAJ2=PVQcW8UGNnSy=Ow=vUK2zpjowTkzUS1B864REa7LOT140Q@mail.gmail.com.Well, if it's been broken since (at least) 2013, and we've had only one
complaint, then I'd say there are too few potential users to justify
the maintenance burden.
I agree.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2017-04-07 13:00:39 +0200, Magnus Hagander wrote:
Insurmountable, probably not. The big difference is that you don't need
*any* dependencies to build a libpq using win32.mak, but you need many of
them (to start with, perl...) to build using the built-in one. For people
who want to build it, it certainly save a lot more than "a few minutes".
For somebody who doesn't have ready scripts it takes a *long* time to set
up a build environment to do our regular msvc builds.
For a useful libpq you actually need a good chunk of dependencies,
including openssl.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 7, 2017 at 4:03 PM, Andrew Dunstan <
andrew.dunstan@2ndquadrant.com> wrote:
On 04/07/2017 09:58 AM, Tom Lane wrote:
This seems be the same as the 2nd error that was reported back in 2013:
/messages/by-id/CAJ2=PVQcW8UGNnSy=Ow%253DvUK2zpjowTkzUS1B864REa7LOT140Q%40mail.gmail.com.
Well, if it's been broken since (at least) 2013, and we've had only one
complaint, then I'd say there are too few potential users to justify
the maintenance burden.I agree.
Are these votes for getting rid of both win32.mak and bcc32.mak?
If so, count me in for the same :) Want me to do the honors, as it's my
fault they're in there in the first place?
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
I'm for it.
If so, count me in for the same :) Want me to do the honors, as it's my
fault they're in there in the first place?
Sure.
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
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
I'm for it.
+1.
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Apr 10, 2017 at 2:07 PM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Mon, Apr 10, 2017 at 8:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
I'm for it.
+1.
PFA a patch that does this. Did I miss something? :)
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
Attachments:
remove_bcc_and_win32_mak.patchtext/x-patch; charset=US-ASCII; name=remove_bcc_and_win32_mak.patchDownload
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index b95b04f..f5dfb91 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
@@ -35,14 +35,6 @@
</para>
<para>
- Finally, the client access library
- (<application>libpq</application>) can be built using
- <productname>Visual C++ 7.1</productname> or
- <productname>Borland C++</productname> for compatibility with statically
- linked applications built using these tools.
- </para>
-
- <para>
Building using <productname>MinGW</productname> or
<productname>Cygwin</productname> uses the normal build system, see
<xref linkend="installation"> and the specific notes in
@@ -539,113 +531,4 @@ $ENV{DOCROOT}='c:\docbook';
</sect2>
</sect1>
-
- <sect1 id="install-windows-libpq">
- <title>Building <application>libpq</application> with
- <productname>Visual C++</productname> or
- <productname>Borland C++</productname></title>
-
- <para>
- Using <productname>Visual C++ 7.1-9.0</productname> or
- <productname>Borland C++</productname> to build libpq is only recommended
- if you need a version with different debug/release flags, or if you need a
- static library to link into an application. For normal use the
- <productname>MinGW</productname> or
- <productname>Visual Studio</productname> or
- <productname>Windows SDK</productname> method is recommended.
- </para>
-
- <para>
- To build the <application>libpq</application> client library using
- <productname>Visual Studio 7.1 or later</productname>, change into the
- <filename>src</filename> directory and type the command:
-<screen>
-<userinput>nmake /f win32.mak</userinput>
-</screen>
- </para>
- <para>
- To build a 64-bit version of the <application>libpq</application>
- client library using <productname>Visual Studio 8.0 or
- later</productname>, change into the <filename>src</filename>
- directory and type in the command:
-<screen>
-<userinput>nmake /f win32.mak CPU=AMD64</userinput>
-</screen>
- See the <filename>win32.mak</filename> file for further details
- about supported variables.
- </para>
-
- <para>
- To build the <application>libpq</application> client library using
- <productname>Borland C++</productname>, change into the
- <filename>src</filename> directory and type the command:
-<screen>
-<userinput>make -N -DCFG=Release /f bcc32.mak</userinput>
-</screen>
- </para>
-
- <sect2>
- <title>Generated Files</title>
- <para>
- The following files will be built:
-
- <variablelist>
- <varlistentry>
- <term><filename>interfaces\libpq\Release\libpq.dll</filename></term>
- <listitem>
- <para>
- The dynamically linkable frontend library
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>interfaces\libpq\Release\libpqdll.lib</filename></term>
- <listitem>
- <para>
- Import library to link your programs to <filename>libpq.dll</filename>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><filename>interfaces\libpq\Release\libpq.lib</filename></term>
- <listitem>
- <para>
- Static version of the frontend library
- </para>
- </listitem>
- </varlistentry>
-
- </variablelist>
- </para>
-
- <para>
- Normally you do not need to install any of the client files. You should
- place the <filename>libpq.dll</filename> file in the same directory
- as your applications executable file. Do not install
- <filename>libpq.dll</filename> into your <filename>Windows</>,
- <filename>System</> or <filename>System32</> directory unless
- absolutely necessary.
- If this file is installed using a setup program, then it should
- be installed with version checking using the
- <symbol>VERSIONINFO</symbol> resource included in the file, to
- ensure that a newer version of the library is not overwritten.
- </para>
-
- <para>
- If you are planning to do development using <application>libpq</application>
- on this machine, you will have to add the
- <filename>src\include</filename> and
- <filename>src\interfaces\libpq</filename> subdirectories of the source
- tree to the include path in your compiler's settings.
- </para>
-
- <para>
- To use the library, you must add the
- <filename>libpqdll.lib</filename> file to your project. (In Visual
- C++, just right-click on the project and choose to add it.)
- </para>
- </sect2>
- </sect1>
</chapter>
diff --git a/src/Makefile.shlib b/src/Makefile.shlib
index 35e2dd8..0ce6d2a 100644
--- a/src/Makefile.shlib
+++ b/src/Makefile.shlib
@@ -405,30 +405,22 @@ endif # PORTNAME == cygwin || PORTNAME == win32
# tarballs.
ifneq (,$(SHLIB_EXPORTS))
-distprep: lib$(NAME)dll.def lib$(NAME)ddll.def blib$(NAME)dll.def
+distprep: lib$(NAME)dll.def lib$(NAME)ddll.def
UC_NAME = $(shell echo $(NAME) | tr 'abcdefghijklmnopqrstuvwxyz' 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')
lib$(NAME)dll.def: $(SHLIB_EXPORTS)
- echo '; DEF file for win32.mak release build and for Makefile.shlib (MinGW)' >$@
+ echo '; DEF file for Makefile.shlib (MinGW)' >$@
echo 'LIBRARY LIB$(UC_NAME).dll' >>$@
echo 'EXPORTS' >>$@
sed -e '/^#/d' -e 's/^\(.*[ ]\)\([0-9][0-9]*\)/ \1@ \2/' $< >>$@
lib$(NAME)ddll.def: $(SHLIB_EXPORTS)
- echo '; DEF file for win32.mak debug build' >$@
+ echo '; DEF file for Makefile.shlib (MinGW)' >$@
echo 'LIBRARY LIB$(UC_NAME)D.dll' >>$@
echo 'EXPORTS' >>$@
sed -e '/^#/d' -e 's/^\(.*[ ]\)\([0-9][0-9]*\)/ \1@ \2/' $< >>$@
-blib$(NAME)dll.def: $(SHLIB_EXPORTS)
- echo '; DEF file for bcc32.mak (Borland C++ Builder)' >$@
- echo 'LIBRARY BLIB$(UC_NAME)' >>$@
- echo 'EXPORTS' >>$@
- sed -e '/^#/d' -e 's/^\(.*[ ]\)\([0-9][0-9]*\)/ _\1@ \2/' $< >>$@
- echo >>$@
- echo '; Aliases for MS compatible names' >> $@
- sed -e '/^#/d' -e 's/^\(.*[ ]\)\([0-9][0-9]*\)/ \1= _\1/' $< | sed 's/ *$$//' >>$@
endif # SHLIB_EXPORTS
@@ -517,5 +509,5 @@ clean-lib:
ifneq (,$(SHLIB_EXPORTS))
maintainer-clean-lib:
- rm -f lib$(NAME)dll.def lib$(NAME)ddll.def blib$(NAME)dll.def
+ rm -f lib$(NAME)dll.def lib$(NAME)ddll.def
endif
diff --git a/src/bcc32.mak b/src/bcc32.mak
deleted file mode 100644
index c691924..0000000
--- a/src/bcc32.mak
+++ /dev/null
@@ -1,47 +0,0 @@
-# src/bcc32.mak
-
-# Makefile for Borland C++ 5.5 (or compat)
-# Top-file makefile for building Win32 libpq with Borland C++.
-
-!IF "$(CFG)" != "Release" && "$(CFG)" != "Debug"
-!MESSAGE Invalid configuration "$(CFG)" specified.
-!MESSAGE You can specify a configuration when running MAKE
-!MESSAGE by defining the macro CFG on the command line. For example:
-!MESSAGE
-!MESSAGE make -DCFG=[Release | Debug] /f bcc32.mak
-!MESSAGE
-!MESSAGE Possible choices for configuration are:
-!MESSAGE
-!MESSAGE "Release" (Win32 Release)
-!MESSAGE "Debug" (Win32 Debug)
-!MESSAGE
-!ENDIF
-
-!IF "$(OS)" == "Windows_NT"
-NULL=
-!ELSE
-NULL=nul
-!ENDIF
-
-ALL:
- cd include
- if not exist pg_config.h copy pg_config.h.win32 pg_config.h
- if not exist pg_config_ext.h copy pg_config_ext.h.win32 pg_config_ext.h
- if not exist pg_config_os.h copy port\win32.h pg_config_os.h
- cd ..
- cd interfaces\libpq
- make -N -DCFG=$(CFG) /f bcc32.mak
- cd ..\..
- echo All Win32 parts have been built!
-
-CLEAN:
- cd interfaces\libpq
- make -N -DCFG=Release /f bcc32.mak CLEAN
- make -N -DCFG=Debug /f bcc32.mak CLEAN
- cd ..\..
- echo All Win32 parts have been cleaned!
-
-DISTCLEAN: CLEAN
- cd include
- del pg_config.h pg_config_ext.h pg_config_os.h
- cd ..
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 494f468..859ded7 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -8,10 +8,6 @@
#include "postgres_fe.h"
#include "command.h"
-#ifdef __BORLANDC__ /* needed for BCC */
-#undef mkdir
-#endif
-
#include <ctype.h>
#include <time.h>
#include <pwd.h>
diff --git a/src/include/getaddrinfo.h b/src/include/getaddrinfo.h
index 952cd44..b24afc5 100644
--- a/src/include/getaddrinfo.h
+++ b/src/include/getaddrinfo.h
@@ -44,10 +44,8 @@
#ifndef WSA_NOT_ENOUGH_MEMORY
#define WSA_NOT_ENOUGH_MEMORY (WSAENOBUFS)
#endif
-#ifndef __BORLANDC__
#define WSATYPE_NOT_FOUND (WSABASEERR+109)
#endif
-#endif
#define EAI_AGAIN WSATRY_AGAIN
#define EAI_BADFLAGS WSAEINVAL
#define EAI_FAIL WSANO_RECOVERY
diff --git a/src/include/port.h b/src/include/port.h
index f454601..f963553 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -403,7 +403,7 @@ extern size_t strlcat(char *dst, const char *src, size_t siz);
extern size_t strlcpy(char *dst, const char *src, size_t siz);
#endif
-#if !defined(HAVE_RANDOM) && !defined(__BORLANDC__)
+#if !defined(HAVE_RANDOM)
extern long random(void);
#endif
diff --git a/src/include/port/atomics/generic-msvc.h b/src/include/port/atomics/generic-msvc.h
index d5ee6e1..f82cfec 100644
--- a/src/include/port/atomics/generic-msvc.h
+++ b/src/include/port/atomics/generic-msvc.h
@@ -23,7 +23,6 @@
#error "should be included via atomics.h"
#endif
-/* Should work on both MSVC and Borland. */
#pragma intrinsic(_ReadWriteBarrier)
#define pg_compiler_barrier_impl() _ReadWriteBarrier()
diff --git a/src/include/port/win32.h b/src/include/port/win32.h
index 4453c90..8cc619f 100644
--- a/src/include/port/win32.h
+++ b/src/include/port/win32.h
@@ -1,6 +1,6 @@
/* src/include/port/win32.h */
-#if defined(_MSC_VER) || defined(__BORLANDC__)
+#if defined(_MSC_VER)
#define WIN32_ONLY_COMPILER
#endif
@@ -32,9 +32,7 @@
* Always build with SSPI support. Keep it as a #define in case
* we want a switch to disable it sometime in the future.
*/
-#ifndef __BORLANDC__
#define ENABLE_SSPI 1
-#endif
/* undefine and redefine after #include */
#undef mkdir
@@ -56,9 +54,7 @@
#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 */
@@ -207,10 +203,8 @@
#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
/*
* New versions of mingw have gettimeofday() and also declare
@@ -421,7 +415,7 @@ extern int pgwin32_is_admin(void);
#define putenv(x) pgwin32_putenv(x)
#define unsetenv(x) pgwin32_unsetenv(x)
-/* Things that exist in MingW headers, but need to be added to MSVC & BCC */
+/* Things that exist in MingW headers, but need to be added to MSVC */
#ifdef WIN32_ONLY_COMPILER
#ifndef _WIN64
@@ -430,7 +424,6 @@ typedef long ssize_t;
typedef __int64 ssize_t;
#endif
-#ifndef __BORLANDC__
typedef unsigned short mode_t;
#define S_IRUSR _S_IREAD
@@ -440,7 +433,6 @@ typedef unsigned short mode_t;
/* see also S_IRGRP etc below */
#define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
#define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
-#endif /* __BORLANDC__ */
#define F_OK 0
#define W_OK 2
@@ -454,26 +446,9 @@ typedef unsigned short mode_t;
/* Pulled from Makefile.port in mingw */
#define DLSUFFIX ".dll"
-#ifdef __BORLANDC__
-
-/* for port/dirent.c */
-#ifndef INVALID_FILE_ATTRIBUTES
-#define INVALID_FILE_ATTRIBUTES ((DWORD) -1)
-#endif
-
-/* for port/open.c */
-#ifndef O_RANDOM
-#define O_RANDOM 0x0010 /* File access is primarily random */
-#define O_SEQUENTIAL 0x0020 /* File access is primarily sequential */
-#define O_TEMPORARY 0x0040 /* Temporary file bit */
-#define O_SHORT_LIVED 0x1000 /* Temporary storage file, try not to flush */
-#define _O_SHORT_LIVED O_SHORT_LIVED
-#endif /* ifndef O_RANDOM */
-#endif /* __BORLANDC__ */
#endif /* WIN32_ONLY_COMPILER */
/* These aren't provided by either MingW or MSVC */
-#ifndef __BORLANDC__
#define S_IRGRP 0
#define S_IWGRP 0
#define S_IXGRP 0
@@ -482,5 +457,3 @@ typedef unsigned short mode_t;
#define S_IWOTH 0
#define S_IXOTH 0
#define S_IRWXO 0
-
-#endif /* __BORLANDC__ */
diff --git a/src/interfaces/libpq/bcc32.mak b/src/interfaces/libpq/bcc32.mak
deleted file mode 100644
index f541fa8..0000000
--- a/src/interfaces/libpq/bcc32.mak
+++ /dev/null
@@ -1,312 +0,0 @@
-# Makefile for Borland C++ 5.5
-
-# Will build a Win32 static library libpq.lib
-# and a Win32 dynamic library libpq.dll with import library libpqdll.lib
-
-# Borland C++ base install directory goes here
-# BCB=c:\Borland\Bcc55
-
-!IF "$(BCB)" == ""
-!MESSAGE You must edit bcc32.mak and define BCB at the top
-!ERROR missing BCB
-!ENDIF
-
-!IF "$(__NMAKE__)" == ""
-!MESSAGE You must use the -N compatibility flag, e.g. make -N -f bcc32.make
-!ERROR missing -N
-!ENDIF
-
-!MESSAGE Building the Win32 DLL and Static Library...
-!MESSAGE
-!IF "$(CFG)" == ""
-CFG=Release
-!MESSAGE No configuration specified. Defaulting to Release.
-!MESSAGE
-!ELSE
-!MESSAGE Configuration "$(CFG)"
-!MESSAGE
-!ENDIF
-
-!IF "$(CFG)" != "Release" && "$(CFG)" != "Debug"
-!MESSAGE Invalid configuration "$(CFG)" specified.
-!MESSAGE You can specify a configuration when running MAKE
-!MESSAGE by defining the macro CFG on the command line. For example:
-!MESSAGE
-!MESSAGE make -N -DCFG=[Release | Debug] -f bcc32.mak
-!MESSAGE
-!MESSAGE Possible choices for configuration are:
-!MESSAGE
-!MESSAGE "Release" (Win32 Release DLL and Static Library)
-!MESSAGE "Debug" (Win32 Debug DLL and Static Library)
-!MESSAGE
-!ERROR An invalid configuration was specified.
-!ENDIF
-
-!IF "$(OS)" == "Windows_NT"
-NULL=
-!ELSE
-NULL=nul
-!ENDIF
-
-!IF "$(CFG)" == "Debug"
-DEBUG=1
-OUTDIR=.\Debug
-INTDIR=.\Debug
-!ELSE
-OUTDIR=.\Release
-INTDIR=.\Release
-!ENDIF
-
-OUTFILENAME=blibpq
-
-USERDEFINES=FRONTEND;NDEBUG;WIN32;_WINDOWS
-
-CPP=bcc32.exe
-CPP_PROJ = -I..\..\include\port\win32_msvc;$(BCB)\include;..\..\include;..\..\include\port\win32;..\..\port -n"$(INTDIR)" -WD -c -D$(USERDEFINES) -tWM \
- -a8 -X -w-use -w-par -w-pia -w-csu -w-aus -w-ccc
-
-!IFDEF DEBUG
-CPP_PROJ = $(CPP_PROJ) -Od -r- -k -v -y -vi- -D_DEBUG
-!else
-CPP_PROJ = $(CPP_PROJ) -O -Oi -OS -DNDEBUG
-!endif
-
-ALL : config "$(OUTDIR)" "$(OUTDIR)\blibpq.dll" "$(OUTDIR)\blibpq.lib"
-
-CLEAN :
- -@erase "$(INTDIR)\getaddrinfo.obj"
- -@erase "$(INTDIR)\pgstrcasecmp.obj"
- -@erase "$(INTDIR)\pqsignal.obj"
- -@erase "$(INTDIR)\thread.obj"
- -@erase "$(INTDIR)\inet_aton.obj"
- -@erase "$(INTDIR)\crypt.obj"
- -@erase "$(INTDIR)\noblock.obj"
- -@erase "$(INTDIR)\chklocale.obj"
- -@erase "$(INTDIR)\inet_net_ntop.obj"
- -@erase "$(INTDIR)\md5.obj"
- -@erase "$(INTDIR)\ip.obj"
- -@erase "$(INTDIR)\fe-auth.obj"
- -@erase "$(INTDIR)\fe-protocol2.obj"
- -@erase "$(INTDIR)\fe-protocol3.obj"
- -@erase "$(INTDIR)\fe-connect.obj"
- -@erase "$(INTDIR)\fe-exec.obj"
- -@erase "$(INTDIR)\fe-lobj.obj"
- -@erase "$(INTDIR)\fe-misc.obj"
- -@erase "$(INTDIR)\fe-print.obj"
- -@erase "$(INTDIR)\fe-secure.obj"
- -@erase "$(INTDIR)\libpq-events.obj"
- -@erase "$(INTDIR)\pqexpbuffer.obj"
- -@erase "$(INTDIR)\win32.obj"
- -@erase "$(INTDIR)\wchar.obj"
- -@erase "$(INTDIR)\encnames.obj"
- -@erase "$(INTDIR)\pthread-win32.obj"
- -@erase "$(INTDIR)\snprintf.obj"
- -@erase "$(INTDIR)\strlcpy.obj"
- -@erase "$(INTDIR)\dirent.obj"
- -@erase "$(INTDIR)\dirmod.obj"
- -@erase "$(INTDIR)\pgsleep.obj"
- -@erase "$(INTDIR)\open.obj"
- -@erase "$(INTDIR)\system.obj"
- -@erase "$(INTDIR)\win32error.obj"
- -@erase "$(OUTDIR)\$(OUTFILENAME).lib"
- -@erase "$(OUTDIR)\$(OUTFILENAME)dll.lib"
- -@erase "$(OUTDIR)\libpq.res"
- -@erase "$(OUTDIR)\$(OUTFILENAME).dll"
- -@erase "$(OUTDIR)\$(OUTFILENAME).tds"
- -@erase "$(INTDIR)\pg_config_paths.h"
-
-
-LIB32=tlib.exe
-LIB32_FLAGS=
-LIB32_OBJS= \
- "$(INTDIR)\win32.obj" \
- "$(INTDIR)\getaddrinfo.obj" \
- "$(INTDIR)\pgstrcasecmp.obj" \
- "$(INTDIR)\pqsignal.obj" \
- "$(INTDIR)\thread.obj" \
- "$(INTDIR)\inet_aton.obj" \
- "$(INTDIR)\crypt.obj" \
- "$(INTDIR)\noblock.obj" \
- "$(INTDIR)\chklocale.obj" \
- "$(INTDIR)\inet_net_ntop.obj" \
- "$(INTDIR)\md5.obj" \
- "$(INTDIR)\ip.obj" \
- "$(INTDIR)\fe-auth.obj" \
- "$(INTDIR)\fe-protocol2.obj" \
- "$(INTDIR)\fe-protocol3.obj" \
- "$(INTDIR)\fe-connect.obj" \
- "$(INTDIR)\fe-exec.obj" \
- "$(INTDIR)\fe-lobj.obj" \
- "$(INTDIR)\fe-misc.obj" \
- "$(INTDIR)\fe-print.obj" \
- "$(INTDIR)\fe-secure.obj" \
- "$(INTDIR)\libpq-events.obj" \
- "$(INTDIR)\pqexpbuffer.obj" \
- "$(INTDIR)\wchar.obj" \
- "$(INTDIR)\encnames.obj" \
- "$(INTDIR)\snprintf.obj" \
- "$(INTDIR)\strlcpy.obj" \
- "$(INTDIR)\dirent.obj" \
- "$(INTDIR)\dirmod.obj" \
- "$(INTDIR)\pgsleep.obj" \
- "$(INTDIR)\open.obj" \
- "$(INTDIR)\system.obj" \
- "$(INTDIR)\win32error.obj" \
- "$(INTDIR)\pthread-win32.obj"
-
-
-config: ..\..\include\pg_config.h ..\..\include\pg_config_ext.h ..\..\include\pg_config_os.h pg_config_paths.h
-
-..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
- copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
-
-..\..\include\pg_config_ext.h: ..\..\include\pg_config_ext.h.win32
- copy ..\..\include\pg_config_ext.h.win32 ..\..\include\pg_config_ext.h
-
-..\..\include\pg_config_os.h: ..\..\include\port\win32.h
- copy ..\..\include\port\win32.h ..\..\include\pg_config_os.h
-
-# Have to use \# so # isn't treated as a comment, but MSVC doesn't like this
-pg_config_paths.h: bcc32.mak
- echo \#define SYSCONFDIR "" > pg_config_paths.h
-
-"$(OUTDIR)" :
- @if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
-
-RSC=brcc32.exe
-RSC_PROJ=-l 0x409 -i$(BCB)\include -fo"$(INTDIR)\libpq.res"
-
-LINK32=ilink32.exe
-LINK32_FLAGS = -Gn -L$(BCB)\lib;$(INTDIR); -x -Tpd -v
-
-# @<< is a Response file, http://www.opussoftware.com/tutorial/TutMakefile.htm
-
-"$(OUTDIR)\blibpq.dll": "$(OUTDIR)\blibpq.lib" "$(INTDIR)\libpq.res" blibpqdll.def
- $(LINK32) @<<
- $(LINK32_FLAGS) +
- c0d32.obj , +
- $@,, +
- "$(OUTDIR)\blibpq.lib" import32.lib cw32mt.lib, +
- blibpqdll.def,"$(INTDIR)\libpq.res"
-<<
- implib -w "$(OUTDIR)\blibpqdll.lib" blibpqdll.def $@
-
-"$(INTDIR)\libpq.res" : "$(INTDIR)" libpq-dist.rc
- $(RSC) $(RSC_PROJ) libpq-dist.rc
-
-"$(OUTDIR)\blibpq.lib": $(LIB32_OBJS)
- $(LIB32) $@ @<<
-+-"$(**: =" &^
-+-")"
-<<
-
-
-"$(INTDIR)\getaddrinfo.obj" : ..\..\port\getaddrinfo.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\getaddrinfo.c
-<<
-
-"$(INTDIR)\pgstrcasecmp.obj" : ..\..\port\pgstrcasecmp.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\pgstrcasecmp.c
-<<
-
-"$(INTDIR)\pqsignal.obj" : ..\..\port\pqsignal.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\pqsignal.c
-<<
-
-"$(INTDIR)\thread.obj" : ..\..\port\thread.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\thread.c
-<<
-
-"$(INTDIR)\inet_aton.obj" : ..\..\port\inet_aton.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\inet_aton.c
-<<
-
-"$(INTDIR)\crypt.obj" : ..\..\port\crypt.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\crypt.c
-<<
-
-"$(INTDIR)\noblock.obj" : ..\..\port\noblock.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\noblock.c
-<<
-
-"$(INTDIR)\chklocale.obj" : ..\..\port\chklocale.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\chklocale.c
-<<
-
-"$(INTDIR)\inet_net_ntop.obj" : ..\..\port\inet_net_ntop.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\inet_net_ntop.c
-<<
-
-"$(INTDIR)\md5.obj" : ..\..\backend\libpq\md5.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\backend\libpq\md5.c
-<<
-
-"$(INTDIR)\ip.obj" : ..\..\backend\libpq\ip.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\backend\libpq\ip.c
-<<
-
-"$(INTDIR)\wchar.obj" : ..\..\backend\utils\mb\wchar.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\backend\utils\mb\wchar.c
-<<
-
-
-"$(INTDIR)\encnames.obj" : ..\..\backend\utils\mb\encnames.c
- $(CPP) @<<
- $(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) /I"." ..\..\port\strlcpy.c
-<<
-
-"$(INTDIR)\dirent.obj" : ..\..\port\dirent.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\dirent.c
-<<
-
-"$(INTDIR)\dirmod.obj" : ..\..\port\dirmod.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\dirmod.c
-<<
-
-"$(INTDIR)\pgsleep.obj" : ..\..\port\pgsleep.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\pgsleep.c
-<<
-
-"$(INTDIR)\open.obj" : ..\..\port\open.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\open.c
-<<
-
-"$(INTDIR)\system.obj" : ..\..\port\system.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\system.c
-<<
-
-"$(INTDIR)\win32error.obj" : ..\..\port\win32error.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\win32error.c
-<<
-
-
-.c.obj:
- $(CPP) $(CPP_PROJ) $<
diff --git a/src/interfaces/libpq/win32.h b/src/interfaces/libpq/win32.h
index be00ea7..c42d7ab 100644
--- a/src/interfaces/libpq/win32.h
+++ b/src/interfaces/libpq/win32.h
@@ -7,17 +7,11 @@
/*
* Some compatibility functions
*/
-#ifdef __BORLANDC__
-#define _timeb timeb
-#define _ftime(a) ftime(a)
-#define _errno errno
-#define popen(a,b) _popen(a,b)
-#else
+
/* open provided elsewhere */
#define close(a) _close(a)
#define read(a,b,c) _read(a,b,c)
#define write(a,b,c) _write(a,b,c)
-#endif
#undef EAGAIN /* doesn't apply on sockets */
#undef EINTR
diff --git a/src/interfaces/libpq/win32.mak b/src/interfaces/libpq/win32.mak
deleted file mode 100644
index 268991e..0000000
--- a/src/interfaces/libpq/win32.mak
+++ /dev/null
@@ -1,366 +0,0 @@
-# Makefile for Microsoft Visual C++ 7.1-8.0
-
-# Will build a static library libpq(d).lib
-# and a dynamic library libpq(d).dll with import library libpq(d)dll.lib
-# USE_OPENSSL=1 will compile with OpenSSL
-# USE_KFW=1 will compile with kfw(kerberos for Windows)
-# DEBUG=1 compiles with debugging symbols
-# ENABLE_THREAD_SAFETY=1 compiles with threading enabled
-
-ENABLE_THREAD_SAFETY=1
-
-# CPU="i386" or CPU environment of nmake.exe (AMD64 or IA64)
-
-!IF ("$(CPU)" == "")||("$(CPU)" == "i386")
-CPU=i386
-!MESSAGE Building the Win32 static library...
-!MESSAGE
-!ELSEIF ("$(CPU)" == "IA64")||("$(CPU)" == "AMD64")
-ADD_DEFINES=/Wp64 /GS
-ADD_SECLIB=bufferoverflowU.lib
-!MESSAGE Building the Win64 static library...
-!MESSAGE
-!ELSE
-!MESSAGE Please check a CPU=$(CPU) ?
-!MESSAGE CPU=i386 or AMD64 or IA64
-!ERROR Make aborted.
-!ENDIF
-
-!IFDEF DEBUG
-OPT=/Od /Zi /MDd
-LOPT=/DEBUG
-DEBUGDEF=/D _DEBUG
-OUTFILENAME=libpqd
-!ELSE
-OPT=/O2 /MD
-LOPT=
-DEBUGDEF=/D NDEBUG
-OUTFILENAME=libpq
-!ENDIF
-
-!IF "$(SSL_INC)" == ""
-SSL_INC=C:\OpenSSL\include
-!MESSAGE Using default OpenSSL Include directory: $(SSL_INC)
-!ENDIF
-
-!IF "$(SSL_LIB_PATH)" == ""
-SSL_LIB_PATH=C:\OpenSSL\lib\VC
-!MESSAGE Using default OpenSSL Library directory: $(SSL_LIB_PATH)
-!ENDIF
-
-!IF "$(KFW_INC)" == ""
-KFW_INC=C:\kfw-2.6.5\inc
-!MESSAGE Using default Kerberos Include directory: $(KFW_INC)
-!ENDIF
-
-!IF "$(KFW_LIB_PATH)" == ""
-KFW_LIB_PATH=C:\kfw-2.6.5\lib\$(CPU)
-!MESSAGE Using default Kerberos Library directory: $(KFW_LIB_PATH)
-!ENDIF
-
-!IF "$(OS)" == "Windows_NT"
-NULL=
-!ELSE
-NULL=nul
-!ENDIF
-
-CPP=cl.exe
-RSC=rc.exe
-
-!IFDEF DEBUG
-OUTDIR=.\Debug
-INTDIR=.\Debug
-CPP_OBJS=.\Debug/
-!ELSE
-OUTDIR=.\Release
-INTDIR=.\Release
-CPP_OBJS=.\Release/
-!ENDIF
-
-
-ALL : config "$(OUTDIR)\$(OUTFILENAME).lib" "$(OUTDIR)\$(OUTFILENAME).dll"
-
-CLEAN :
- -@erase "$(INTDIR)\getaddrinfo.obj"
- -@erase "$(INTDIR)\pgstrcasecmp.obj"
- -@erase "$(INTDIR)\pqsignal.obj"
- -@erase "$(INTDIR)\thread.obj"
- -@erase "$(INTDIR)\inet_aton.obj"
- -@erase "$(INTDIR)\crypt.obj"
- -@erase "$(INTDIR)\noblock.obj"
- -@erase "$(INTDIR)\chklocale.obj"
- -@erase "$(INTDIR)\inet_net_ntop.obj"
- -@erase "$(INTDIR)\md5.obj"
- -@erase "$(INTDIR)\ip.obj"
- -@erase "$(INTDIR)\fe-auth.obj"
- -@erase "$(INTDIR)\fe-protocol2.obj"
- -@erase "$(INTDIR)\fe-protocol3.obj"
- -@erase "$(INTDIR)\fe-connect.obj"
- -@erase "$(INTDIR)\fe-exec.obj"
- -@erase "$(INTDIR)\fe-lobj.obj"
- -@erase "$(INTDIR)\fe-misc.obj"
- -@erase "$(INTDIR)\fe-print.obj"
- -@erase "$(INTDIR)\fe-secure.obj"
- -@erase "$(INTDIR)\libpq-events.obj"
- -@erase "$(INTDIR)\pqexpbuffer.obj"
- -@erase "$(INTDIR)\win32.obj"
- -@erase "$(INTDIR)\wchar.obj"
- -@erase "$(INTDIR)\encnames.obj"
- -@erase "$(INTDIR)\pthread-win32.obj"
- -@erase "$(INTDIR)\snprintf.obj"
- -@erase "$(INTDIR)\strlcpy.obj"
- -@erase "$(INTDIR)\dirent.obj"
- -@erase "$(INTDIR)\dirmod.obj"
- -@erase "$(INTDIR)\pgsleep.obj"
- -@erase "$(INTDIR)\open.obj"
- -@erase "$(INTDIR)\system.obj"
- -@erase "$(INTDIR)\win32error.obj"
- -@erase "$(INTDIR)\win32setlocale.obj"
- -@erase "$(OUTDIR)\$(OUTFILENAME).lib"
- -@erase "$(OUTDIR)\$(OUTFILENAME)dll.lib"
- -@erase "$(OUTDIR)\libpq.res"
- -@erase "$(OUTDIR)\$(OUTFILENAME).dll"
- -@erase "$(OUTDIR)\$(OUTFILENAME)dll.exp"
- -@erase "$(OUTDIR)\$(OUTFILENAME).dll.manifest"
- -@erase "$(OUTDIR)\*.idb"
- -@erase pg_config_paths.h"
-!IFDEF USE_OPENSSL
- -@erase "$(INTDIR)\fe-secure-openssl.obj"
-!ENDIF
-
-
-LIB32=link.exe -lib
-LIB32_FLAGS=$(LOPT) /nologo /out:"$(OUTDIR)\$(OUTFILENAME).lib"
-LIB32_OBJS= \
- "$(INTDIR)\win32.obj" \
- "$(INTDIR)\getaddrinfo.obj" \
- "$(INTDIR)\pgstrcasecmp.obj" \
- "$(INTDIR)\pqsignal.obj" \
- "$(INTDIR)\thread.obj" \
- "$(INTDIR)\inet_aton.obj" \
- "$(INTDIR)\crypt.obj" \
- "$(INTDIR)\noblock.obj" \
- "$(INTDIR)\chklocale.obj" \
- "$(INTDIR)\inet_net_ntop.obj" \
- "$(INTDIR)\md5.obj" \
- "$(INTDIR)\ip.obj" \
- "$(INTDIR)\fe-auth.obj" \
- "$(INTDIR)\fe-protocol2.obj" \
- "$(INTDIR)\fe-protocol3.obj" \
- "$(INTDIR)\fe-connect.obj" \
- "$(INTDIR)\fe-exec.obj" \
- "$(INTDIR)\fe-lobj.obj" \
- "$(INTDIR)\fe-misc.obj" \
- "$(INTDIR)\fe-print.obj" \
- "$(INTDIR)\fe-secure.obj" \
- "$(INTDIR)\libpq-events.obj" \
- "$(INTDIR)\pqexpbuffer.obj" \
- "$(INTDIR)\wchar.obj" \
- "$(INTDIR)\encnames.obj" \
- "$(INTDIR)\snprintf.obj" \
- "$(INTDIR)\strlcpy.obj" \
- "$(INTDIR)\dirent.obj" \
- "$(INTDIR)\dirmod.obj" \
- "$(INTDIR)\pgsleep.obj" \
- "$(INTDIR)\open.obj" \
- "$(INTDIR)\system.obj" \
- "$(INTDIR)\win32error.obj" \
- "$(INTDIR)\win32setlocale.obj" \
- "$(INTDIR)\pthread-win32.obj"
-
-!IFDEF USE_OPENSSL
-LIB32_OBJS=$(LIB32_OBJS) "$(INTDIR)\fe-secure-openssl.obj"
-!ENDIF
-
-
-config: ..\..\include\pg_config.h ..\..\include\pg_config_ext.h pg_config_paths.h ..\..\include\pg_config_os.h
-
-..\..\include\pg_config.h: ..\..\include\pg_config.h.win32
- copy ..\..\include\pg_config.h.win32 ..\..\include\pg_config.h
-
-..\..\include\pg_config_ext.h: ..\..\include\pg_config_ext.h.win32
- copy ..\..\include\pg_config_ext.h.win32 ..\..\include\pg_config_ext.h
-
-..\..\include\pg_config_os.h:
- copy ..\..\include\port\win32.h ..\..\include\pg_config_os.h
-
-pg_config_paths.h: win32.mak
- echo #define SYSCONFDIR "" > pg_config_paths.h
-
-"$(OUTDIR)" :
- if not exist "$(OUTDIR)/$(NULL)" mkdir "$(OUTDIR)"
-
-CPP_PROJ=/nologo /W3 /EHsc $(OPT) /I "..\..\include" /I "..\..\include\port\win32" /I "..\..\include\port\win32_msvc" /I "..\..\port" /I. /I "$(SSL_INC)" \
- /D "FRONTEND" $(DEBUGDEF) \
- /D "WIN32" /D "_WINDOWS" /Fp"$(INTDIR)\libpq.pch" \
- /Fo"$(INTDIR)\\" /Fd"$(INTDIR)\\" /FD /c \
- /D "_CRT_SECURE_NO_DEPRECATE" $(ADD_DEFINES)
-
-!IFDEF USE_OPENSSL
-CPP_PROJ=$(CPP_PROJ) /D USE_OPENSSL
-SSL_LIBS=ssleay32.lib libeay32.lib gdi32.lib
-!ENDIF
-
-!IFDEF USE_KFW
-CPP_PROJ=$(CPP_PROJ) /D KRB5
-KFW_LIBS=krb5_32.lib comerr32.lib gssapi32.lib
-!ENDIF
-
-!IFDEF ENABLE_THREAD_SAFETY
-CPP_PROJ=$(CPP_PROJ) /D ENABLE_THREAD_SAFETY
-!ENDIF
-
-CPP_SBRS=.
-
-RSC_PROJ=/l 0x409 /fo"$(INTDIR)\libpq.res"
-
-LINK32=link.exe
-LINK32_FLAGS=kernel32.lib user32.lib advapi32.lib shell32.lib ws2_32.lib secur32.lib $(SSL_LIBS) $(KFW_LIB) $(ADD_SECLIB) \
- /nologo /subsystem:windows /dll $(LOPT) /incremental:no \
- /pdb:"$(OUTDIR)\libpqdll.pdb" /machine:$(CPU) \
- /out:"$(OUTDIR)\$(OUTFILENAME).dll"\
- /implib:"$(OUTDIR)\$(OUTFILENAME)dll.lib" \
- /libpath:"$(SSL_LIB_PATH)" /libpath:"$(KFW_LIB_PATH)" \
- /def:$(OUTFILENAME)dll.def
-LINK32_OBJS= \
- "$(OUTDIR)\$(OUTFILENAME).lib" \
- "$(OUTDIR)\libpq.res"
-
-# @<< is a Response file, http://www.opussoftware.com/tutorial/TutMakefile.htm
-
-"$(OUTDIR)\$(OUTFILENAME).lib" : "$(OUTDIR)" $(DEF_FILE) $(LIB32_OBJS)
- $(LIB32) @<<
- $(LIB32_FLAGS) $(DEF_FLAGS) $(LIB32_OBJS)
-<<
-
-"$(INTDIR)\libpq.res" : "$(INTDIR)" libpq-dist.rc
- $(RSC) $(RSC_PROJ) libpq-dist.rc
-
-
-"$(OUTDIR)\$(OUTFILENAME).dll" : "$(OUTDIR)" "$(INTDIR)\libpq.res"
- $(LINK32) @<<
- $(LINK32_FLAGS) $(LINK32_OBJS)
-<<
-# Inclusion of manifest
-!IF "$(_NMAKE_VER)" != "6.00.8168.0" && "$(_NMAKE_VER)" != "7.00.9466"
-!IF "$(_NMAKE_VER)" != "6.00.9782.0" && "$(_NMAKE_VER)" != "7.10.3077"
- mt -manifest $(OUTDIR)\$(OUTFILENAME).dll.manifest -outputresource:$(OUTDIR)\$(OUTFILENAME).dll;2
-!ENDIF
-!ENDIF
-
-"$(INTDIR)\getaddrinfo.obj" : ..\..\port\getaddrinfo.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\getaddrinfo.c
-<<
-
-"$(INTDIR)\pgstrcasecmp.obj" : ..\..\port\pgstrcasecmp.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\pgstrcasecmp.c
-<<
-
-"$(INTDIR)\pqsignal.obj" : ..\..\port\pqsignal.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\pqsignal.c
-<<
-
-"$(INTDIR)\thread.obj" : ..\..\port\thread.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\thread.c
-<<
-
-"$(INTDIR)\inet_aton.obj" : ..\..\port\inet_aton.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\inet_aton.c
-<<
-
-"$(INTDIR)\crypt.obj" : ..\..\port\crypt.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\crypt.c
-<<
-
-"$(INTDIR)\noblock.obj" : ..\..\port\noblock.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\noblock.c
-<<
-
-"$(INTDIR)\chklocale.obj" : ..\..\port\chklocale.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\chklocale.c
-<<
-
-"$(INTDIR)\inet_net_ntop.obj" : ..\..\port\inet_net_ntop.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\port\inet_net_ntop.c
-<<
-
-"$(INTDIR)\md5.obj" : ..\..\backend\libpq\md5.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\backend\libpq\md5.c
-<<
-
-"$(INTDIR)\ip.obj" : ..\..\backend\libpq\ip.c
- $(CPP) @<<
- $(CPP_PROJ) ..\..\backend\libpq\ip.c
-<<
-
-"$(INTDIR)\wchar.obj" : ..\..\backend\utils\mb\wchar.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\backend\utils\mb\wchar.c
-<<
-
-
-"$(INTDIR)\encnames.obj" : ..\..\backend\utils\mb\encnames.c
- $(CPP) @<<
- $(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) /I"." ..\..\port\strlcpy.c
-<<
-
-"$(INTDIR)\dirent.obj" : ..\..\port\dirent.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\dirent.c
-<<
-
-"$(INTDIR)\dirmod.obj" : ..\..\port\dirmod.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\dirmod.c
-<<
-
-"$(INTDIR)\pgsleep.obj" : ..\..\port\pgsleep.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\pgsleep.c
-<<
-
-"$(INTDIR)\open.obj" : ..\..\port\open.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\open.c
-<<
-
-"$(INTDIR)\system.obj" : ..\..\port\system.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\system.c
-<<
-
-"$(INTDIR)\win32error.obj" : ..\..\port\win32error.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\win32error.c
-<<
-
-"$(INTDIR)\win32setlocale.obj" : ..\..\port\win32setlocale.c
- $(CPP) @<<
- $(CPP_PROJ) /I"." ..\..\port\win32setlocale.c
-<<
-
-.c{$(CPP_OBJS)}.obj:
- $(CPP) $(CPP_PROJ) $<
-
-.c.obj:
- $(CPP) $(CPP_PROJ) $<
diff --git a/src/win32.mak b/src/win32.mak
deleted file mode 100644
index 9699e81..0000000
--- a/src/win32.mak
+++ /dev/null
@@ -1,32 +0,0 @@
-# src/win32.mak
-
-# Top-file makefile for building Win32 libpq with Visual C++ 7.1.
-# (see src/tools/msvc for tools to build with Visual C++ 2005 and newer)
-
-!IF "$(OS)" == "Windows_NT"
-NULL=
-!ELSE
-NULL=nul
-!ENDIF
-
-ALL:
- cd include
- if not exist pg_config.h copy pg_config.h.win32 pg_config.h
- if not exist pg_config_ext.h copy pg_config_ext.h.win32 pg_config_ext.h
- if not exist pg_config_os.h copy port\win32.h pg_config_os.h
- cd ..
- cd interfaces\libpq
- nmake /f win32.mak $(MAKEMACRO)
- cd ..\..
- echo All Win32 parts have been built!
-
-CLEAN:
- cd interfaces\libpq
- nmake /f win32.mak CLEAN
- cd ..\..
- echo All Win32 parts have been cleaned!
-
-DISTCLEAN: CLEAN
- cd include
- del pg_config.h pg_config_ext.h pg_config_os.h
- cd ..
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef _MSC_VER".
Or maybe rename it to something else --- I'm not sure what, but
I've always found that symbol rather confusing.
Looks good other than that nitpick.
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
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef _MSC_VER".
That's here in the patch for people wondering:
-#if defined(_MSC_VER) || defined(__BORLANDC__)
+#if defined(_MSC_VER)
#define WIN32_ONLY_COMPILER
#endif
+1 for the renaming.Or maybe rename it to something else --- I'm not sure what, but
I've always found that symbol rather confusing.
No complains here as well. Thanks for the patch.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:
On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef _MSC_VER".That's here in the patch for people wondering: -#if defined(_MSC_VER) || defined(__BORLANDC__) +#if defined(_MSC_VER) #define WIN32_ONLY_COMPILER #endif +1 for the renaming.
Ok, since we have two votes for it, I will go ahead and do that (as a
separate patch pushed together).'
Or maybe rename it to something else --- I'm not sure what, but
I've always found that symbol rather confusing.
No complains here as well. Thanks for the patch.
Thanks.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
On Tue, Apr 11, 2017 at 03:14:23PM +0200, Magnus Hagander wrote:
On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier <michael.paquier@gmail.com>
wrote:On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
Are these votes for getting rid of both win32.mak and bcc32.mak?
PFA a patch that does this. Did I miss something? :)
Perhaps we should get rid of the WIN32_ONLY_COMPILER symbol altogether;
given this patch, "#ifdef WIN32_ONLY_COMPILER" could be replaced by
"#ifdef _MSC_VER".That's here in the patch for people wondering: -#if defined(_MSC_VER) || defined(__BORLANDC__) +#if defined(_MSC_VER) �#define WIN32_ONLY_COMPILER �#endif +1 for the renaming.Ok, since we have two votes for it, I will go ahead and do that (as a separate
patch pushed together).'
I am fine with removing things, but I do remember one reason the Borland
part was kept is that some tool would only work with the
Borland-compiled library, not gcc or MSVC, but that was long ago.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
I am fine with removing things, but I do remember one reason the Borland
part was kept is that some tool would only work with the
Borland-compiled library, not gcc or MSVC, but that was long ago.
Yeah, very long ago. A quick search of our archives shows that the number
of mentions of Borland pretty much fell off a cliff after 2009 (excluding
the repeated conversations about dropping support, that is). I found one
report suggesting that it was already broken in 2012:
/messages/by-id/AD61A3A7C80949178643FE5D2811C35F@LynnPC
It seems pretty safe to say that nobody's using this build method
anymore. As best I can tell from perusing the archives, the reason
we used to expend a lot of sweat on it was that there was a freely
available version of Borland C and none of MSVC. But that stopped
being true a long time ago, so there's not much reason to concern
ourselves with it anymore.
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
On Tue, Apr 11, 2017 at 04:51:03PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Yeah, very long ago. A quick search of our archives shows that the number
of mentions of Borland pretty much fell off a cliff after 2009 (excluding
the repeated conversations about dropping support, that is). I found one
report suggesting that it was already broken in 2012:/messages/by-id/AD61A3A7C80949178643FE5D2811C35F@LynnPC
It seems pretty safe to say that nobody's using this build method
anymore. As best I can tell from perusing the archives, the reason
we used to expend a lot of sweat on it was that there was a freely
available version of Borland C and none of MSVC. But that stopped
being true a long time ago, so there's not much reason to concern
ourselves with it anymore.
Agreed, I was just pointing out why it remained so long.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers