summaryrefslogtreecommitdiff
path: root/src/interfaces/libpq/win32.mak
Commit message (Collapse)AuthorAgeFilesLines
* MSVC/BCC Win32 compiler fixes.Bruce Momjian2006-10-101-2/+2
| | | | Hiroshi Saito
* Oops, forgot that libpq needs extra steps to make use of src/port/ files.Tom Lane2006-09-271-0/+7
|
* Suppress MSVC warnings about weak functions by usingBruce Momjian2006-08-091-3/+4
| | | | | | _CRT_SECURE_NO_DEPRECATE. Hiroshi Saito
* Move pthread-win32.h to /port, modify bcc/msvc makefiles.Bruce Momjian2006-07-101-1/+1
|
* Prepare code to be built by MSVC:Bruce Momjian2006-06-071-1/+8
| | | | | | | | | | o remove many WIN32_CLIENT_ONLY defines o add WIN32_ONLY_COMPILER define o add 3rd argument to open() for portability o add include/port/win32_msvc directory for system includes Magnus Hagander
* This correction is required of nmake of Windows.Bruce Momjian2005-09-161-4/+1
| | | | Hiroshi Saito
* Cleanup for Win32 compile.Bruce Momjian2005-06-191-1/+4
| | | | Andreas Pflug
* Backpatch BCC compile changes to 8.0.X for psql.Bruce Momjian2005-04-291-62/+34
|
* Properly implement "Response files" for bcc. Add URL's to describe theBruce Momjian2005-03-071-1/+3
| | | | feature for Win32 and bcc.
* Tab indent all actions in bcc32.mak, and do it on win32.mak too forBruce Momjian2005-02-271-37/+37
| | | | consistency. Backpatch only bcc32.mak to 8.0.X.
* Try to get Borland CC to compile.Bruce Momjian2005-02-211-6/+6
| | | | Backpatch to 8.0.X which doesn't work right now.
* Use SHGetFolderPath instead of SHGetSpecialFolderPath to find theTom Lane2005-01-261-1/+1
| | | | APPDATA directory on Windows. Magnus Hagander
* Un-break MSVC build, per Andrew Dunstan.Tom Lane2005-01-101-1/+1
|
* Not entirely sure when this broke, but libpq's VC++ build is currentlyBruce Momjian2004-11-131-0/+2
| | | | | | | | lacking pqsignal which is now required. This was found and fixed for VC++ by Shachar Shemesh, I simply duplicated the fix for the Borland makefile (untested, as I don't have that compiler). Dave Page
* Remove dllist.c from libpq. It's overkill for what libpq needs; we canTom Lane2004-10-161-8/+0
| | | | | | | just stick a list-link into struct PGnotify instead. Result is a smaller faster and more robust library (mainly because we reduce the number of malloc's and free's involved in notify processing), plus less pollution of application link-symbol namespace.
* Remove pg_config_paths.h from libpq *.mak builds so later MinGW buildsBruce Momjian2004-09-021-1/+1
| | | | will succeed.
* Enable thread safety for win32.mak build of PostgreSQL.Bruce Momjian2004-06-191-4/+9
| | | | Andreas Pflug
* The attached patch will create a dummy pg_config_paths.h. Additionally,Bruce Momjian2004-06-041-1/+7
| | | | | | | ENABLE_THREAD_SAFETY is supported by the makefile (but not by the sources, which need some rework) Andreas Pflug
* Add new Win32 file with adjustments for recent code changes.Bruce Momjian2004-06-031-26/+34
| | | | Andreas Pflug
* Corrects issues recently posted by Dann Corbit, allowing libpq/psql toBruce Momjian2004-04-051-0/+7
| | | | | | be built under VC++. Moves a pgstat win32 #def to port.h Claudio Natoli
* Make a separate win32 debug DLL along with the non-debug version:Bruce Momjian2004-03-091-16/+18
| | | | | | | | | | | | | | | | | | | Currently, src/interfaces/libpq/win32.mak builds a statically-linked library "libpq.lib", a debug dll "libpq.dll", import library for the debug dll "libpqdll.lib", a release dll "libpq.dll", import library for the release dll "libpqdll.lib". To avoid naming clashes, I would make the debug dll and import libraries "libpqd.dll" and "libpqddll.lib". Basically, the debug build uses the cl flags: "/MDd /D _DEBUG", and the release build uses the cl flags "/MD /D NDEBUG". Usually the debug build has a "D" suffix on the file name, so for example: libpqd.dll libpq, debug build libpqd.lib libpq, debug build, import library libpq.dll libpq, release build libpq.lib libpq, release build, import library David Turner
* Reorder win32/bcc makefile mentions of thread.c for sanity.Bruce Momjian2003-11-301-2/+3
|
* Enable Win32 to compile libpq again, and enable SSL compiles on thatBruce Momjian2003-09-051-17/+34
| | | | | | platform. Andreas Pflug
* Attached is the complete diff against current CVS.Bruce Momjian2003-06-121-0/+37
| | | | | | Compiles on BCC 5.5 and VC++ 6.0 (with warnings). Karl Waclawek
* Back out patch that got bundled into another patch.Bruce Momjian2003-06-121-33/+0
|
* New patch with corrected README attached.Bruce Momjian2003-06-121-0/+33
| | | | | | Also quickly added mention that it may be a qualified schema name. Rod Taylor
* Remove all traces of multibyte and locale options. Clean up commentsPeter Eisentraut2002-09-031-48/+6
| | | | referring to "multibyte" where it really means character encoding.
* Hello, i noticed that win32 native stopped working/compiling after the SSL mergeBruce Momjian2002-07-201-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | . So i took the opportunity to fix some stuff: 1. Made the thing compile (typos & needed definitions) with the new pqsecure_* s tuff, and added fe-secure.c to the win32.mak makefile. 2. Fixed some MULTIBYTE compile errors (when building without MB support). 3. Made it do that you can build with debug info: "nmake -f win32.mak DEBUG=1". 4. Misc small compiler speedup changes. The resulting .dll has been tested in production, and everything seems ok. I CC:ed -hackers because i'm not sure about two things: 1. In libpq-int.h I typedef ssize_t as an int because Visual C (v6.0) doesn't de fine ssize_t. Is that ok, or is there any standard about what type should be use d for ssize_t? 2. To keep the .dll api consistent regarding MULTIBYTE I just return -1 in fe-connect.c:PQsetClientEncoding() instead of taking away the whole function. I wonder if i should do any compares with the conn->client_encoding and return 0 if not hing would have changed (if so how do i check that?). Regards Magnus Naeslund
* I'm at the win32 error messages once more. The DLL load thingy doesn'tBruce Momjian2002-04-241-3/+4
| | | | | | | | | | | | | | | | work on all win9x machines, so i made it go thru a l ookup table instead, using the DLL as last resort. I also moved this out of the fe-misc.c file because of the size of the lookup ta ble. Who knows, we might add more other win32 specific code there in the future. I also fixed a small typo in the pg_config.h.win32 that made the compiler compla in about the gnu snprintf declaration. I tried to make this patch with psql coding style. I've successfully tested this on win2k and win98 and it works fine (i.e. the mes sage shows on win98 too, it didn't with the old implementation). Magnus Naeslund
* Remove compile errors of psql.exe and libpq.dll underHiroshi Inoue2001-11-221-1/+10
| | | | Multibyte mode.
* Add MD5 to win32.makBruce Momjian2001-08-251-0/+8
|
* Fix win32.mak to support MULTIBYTE build --- it was pulling in severalTom Lane2001-08-031-20/+34
| | | | | backend files that it shouldn't anymore, causing compile failures. Per report from Darko Prenosil.
* Here is an update on the Win32 patch. Modified files are 'config.h.win32'Bruce Momjian2001-01-271-1/+1
| | | | | | | | | | | | | | | | | and two 'win32.mak'. Addresses the following: 1) Oops. Spelled fcntl.h wrong in the last one. D'uh. 2) PG_VERSION changed to be defined with " around it. psql/command.c failed to compile without that. 3) Changed makefiles to use "/MD" and link both psql and libpq.dll against MSVCRT.DLL instead of a static library. This takes care of the crash-upon-free in psql. I *think* this is what is on the "Open 7.1 Items" list as "Magnus Hagander ODBC Issues?". It has nothing to do with ODBC, but it's the only issue I've been involved with... Magnus Hagander
* Update frontend libpq to remove limits on query lengths,Tom Lane1999-08-311-1/+3
| | | | | | | error/notice message lengths, and number of fields per tuple. Add pqexpbuffer.c/.h, a frontend version of backend's stringinfo module. This is first step in applying Mike Ansley's long-query patches, even though he didn't do any of these particular changes...
* Fix for Win32 making problem with MB enabled.Tatsuo Ishii1999-08-161-1/+30
| | | | Patches created by Hiroki Kataoka.
* > Here is a small patch that should only affect win32 buildingBruce Momjian1999-06-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | > (native win32, not cygnus). > It does the following: > Patches two win32.mak files to DEFINE HAVE_VSNPRINTF and > HAVE_STRDUP. This is required to build at all. > Bumps the version number on libpq.dll from 6.4 to 6.5. > Required for install programs to work. > Adds defintions for BLCKSZ and MAXIMUM_ALIGN to "win32.h" in > the client-side libpiq directory. > > All these files are only used when building on native win32, > so it should be safe I think. > > Again, really sorry to throw this in so late, but I would > hate to do the same thing as with 6.4 (which required 6.4.1 > to at all compile on Win32). > > Thanks, > > //Magnus
* Compilation of libpq for Win32 breaks on 6.4, because of a change that IBruce Momjian1998-12-141-1/+1
| | | | | | | | | | | | | | missed before the release. It's simply a symbol that is undefined. This patch defines this symbol in "win32.h", so it should have no effect on any other platforms. It should go into 6.4.1 if possible, since compilation is completely broken without it. I am also attaching a patch for the "win32.mak" file - it leaves a file behind when doing "make clean" after the library is built on Visual C++ 6.0. This is not at all as urgent, but I don't see it breaking here, so I think it might as well go in there too? //Magnus
* Here are the patches against the current source tree. I have run theBruce Momjian1998-10-061-1/+13
| | | | | | | | | | | | | | regression test on a FreeBSD box with both non-MULTIBYTE and MULTIBYTE-enabled, and confirmed that the results are same. However I do not tested on PCs(I don't have access to win). Please let me know if the patches break anything on PCs. Also please note that the patch for varchar.c is a fix for a nasty bug of char(n) types that I introduced and I believe at least this should be applied. Tatsuo Ishii
* Fixes for VC and libpq.Bruce Momjian1998-09-181-1/+1
| | | | Magnus Hagander
* Hello!Bruce Momjian1998-08-291-5/+17
| | | | | | | | | | | | | | | | | | Here is a new patch for libpq, to make it work on Win32 again (since the latest modifications broke it a little). Please also add the file "libpq.rc" to the interfaces/libpq directory. This will allow version-stamping of the generated DLL file, so that automatic install programs (and interested users) can determine the version of the file. The file is currently set as "prerelease". Before the release, somebody should change the line "FILEFLAGS VS_FF_PRERELEASE" to "FILEFLAGS 0". That information should probably go into toos\RELEASE_CHANGES. The patch is against the cvs as of ~ 1998-08-26 14:30 CEST. //Magnus
* Hello!Bruce Momjian1998-07-031-0/+112
Through some minor changes, I have been able to compile the libpq client libraries on the Win32 platform. Since the libpq communications part has been rewritten, this has become much easier. Enclosed is a patch that will allow at least Microsoft Visual C++ to compile libpq into both a static and a dynamic library. I will take a look at porting the psql frontend as well, but I figured it was a good idea to send in these patches first - so no major changes are done to the files before it gets applied (if it does). Regards, Magnus Hagander
View Lorry Controller Status