Just a reminder that I assume all Hackers readers are subscribed to
either the PostgreSQL announce or general lists.

I just posted something to those lists about this URL:

	http://candle.pha.pa.us/oreilly/

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 4 Feb 2001 00:55:30 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Reminder about Announce/General lists

I wanted to get pgaccess working under win32 with MSVC 6. It relies on the 
libpgtcl library, which didn't have a win32.mak. This turned out to be (I 
think) because Tcl_CreateFileChannel function isn't portable to win32 systems.

So I grabbed the relevant files from CVS (no tags), and hacked about a bit 
and now I have a mostly working libpgtcl.dll. The problem is that the 
implementation of pg_listen relies on Tcl_CreateFileChannel, so NOTIFY's 
aren't picked up under win32 until, say, a pg_exec is issued. I had a quick 
look at finding out how to get incoming data on the socket to trigger Tcl 
events, and it looks like it might be possible to build a Tcl event source 
to fetch the NOTIFY events from the backed. That however is not something I 
could do in a day or two.

So now pgaccess works fine - it doesn't use pg_listen.

The other change I made was to move dll exports from the .def file into the 
source code using declspec. A clunky system but IMHO slightly easier to 
work with than the .def files. I found that the Tcl, libpq, and libpgtcl 
source code all use the DLLIMPORT define. This causes some annoying 
conflicts, so I changed each library to have it's own declspec define 
(XXX_STORAGE_CLASS), and each library now needs a define ( 
BUILDING_XXX_DLL) to indicate whether you're building the dll (defined) or 
importing it (undefined). XXX_STORAGE_CLASS would be defined to '' for 
build environments that do shared libraries properly.

This means that for each dll export, for example in 
pgsql/src/interfaces/libpq/libpq-fe.h I have something like

	PQ_STORAGE_CLASS extern PGconn *PQconnectStart(const char *conninfo);

instead of

	extern PGconn *PQconnectStart(const char *conninfo);

There were one or two other minor changes like defining NO_GDI in strategic 
places to prevent a 'macro ERROR redefined' warning, and adding some 
defines to pgsql/src/interfaces/libpq/win32.h, as well as including win32.h 
at the top of pgsql/src/interfaces/libpq/libpq-fe.h. This may need to be in 
a config.h file, or something like that.

I fought with the win32.mak files for a while, but it turned out to be 
easier to use an MSVC 6 Workspace to build libpq, libpgtcl, psql as 
projects. I put it in pgsql/src/win32 - it seemed like a good place. That 
way you don't end up with Debug and Release directories all over the place, 
and you can put your .dlls and .exes and .libs in one place.

Oh and there's an amusing free() assertion failure in the notify handler if 
you don't build with multithread dll runtime, but you guys got that one 
already?

So, to summarise:

1) get libpgtcl working under win32, but with slighly broken pg_listen support
2) export DLL functions differently
3) make win32 builds slightly less noisy
4) create MSVC projects (in src/win32)

Where do I send the diffs and new files? pgsql-patches?

bye
John


Mon, 05 Feb 2001 23:28:53 +0200
John Anderson <panic@semiosix.com>
building libpgtcl for pgaccess under win32, and other stories