Tom,
On Tue, Aug 21, 2001 at 01:39:45PM -0400, Tom Lane wrote:
> Jason Tishler <jason@tishler.net> writes:
> > The first attachment is the root cause of this problem. If I revert
> > pgconnection.h to version 1.11, then Cygwin PostgreSQL (i.e., libpq++)
> > builds cleanly again.
>
> Hmm. What does it mean to attach a DLLIMPORT label to a class, anyway?
That is just a quick way to mark all class members dllexport/dllimport
instead of having to do so for each one individually.
[I probably shouldn't throw fuel on the fire, but...]
FYI, there is a new version of Cygwin binutils that makes the DLLIMPORT
cruft obsolete:
http://www.cygwin.com/ml/cygwin-announce/2001/msg00100.html
In particular, check out Paul Sokolovsky's 'auto-import' functionality.
Oh yeah, I just remembered b20.1. I guess that you can forget about the
above. :,)
> Is it meaningful to do so on Cygwin (as opposed to bare WIN32)?
Cygwin and Win32 should treat DLLIMPORT the same.
> > I tried to build the Win32 stuff to see if the native libpq++ would build
> > cleanly without the DLLIMPORT. Unfortunately, the Win32 build seems to
> > be broken too... See second attachment. Note that I can build 7.1.2
> > under MSVC++. Has the procedure for 7.2 changed?
>
> No, but libpq's CVS tip is busted on WIN32. See ongoing discussions
> about fixing errno and strerror() handling on WIN32. One way or another
> we'll have it fixed soon.
Oops, I'm a little behind in reading pgsql-patches... Or, has this been
discussed on pgsql-hackers?
> BTW, I have no idea whether libpq++ (as opposed to libpq) has ever built
> on WIN32 in the past. The changes you are mentioning seem to be a
> recent attempt to make it do so, which evidently needs further thought.
You are correct. As of 7.1.2, libpq++ was not part of the Win32 build.
Jason