that is shipped in the distribution, named libpq-dist.rc. This way the
build system doesn't get upset when a distributed file is forcibly
overwritten by during a normal build.
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
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
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.
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
.
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
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
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
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...
> (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
