Re: PostgreSQL CVS does not compile under Cygwin (was Re: Cygwin test ...)

Tom,

On Fri, Aug 03, 2001 at 06:16:28PM -0400, Tom Lane wrote:
> I've just finished (I think) cleanup after the recent libpq patches to
> make it work better on Win32. It is alleged that nonblocking mode works
> now on Win32. I am wondering if things are working or broken on Cygwin,
> however. When you get some time, would you pull CVS tip and try it out?

I just built the latest PostgreSQL CVS and ran it against essentially
the latest Cygwin CVS. make check failed with many connection refused
false positives. Previously, I would only get these occasionally. Recall
that Windows NT 4.0 Workstation and 2000 Professional only have a backlog
size of 5. Can the above mentioned changes be the cause of the increased
connection refused failures?

Additionally, I had (test) misc failures, but I believe that is due to the
other failures? Is that assessment correct?

Since the parallel schedule was failing, I decided to try the serial one.
With the serial schedule, all tests passed except for random. Normally,
I wouldn't worry, but random failed every time I ran either version of
the regression test except for once. Does this indicate a problem?

So, I think that Cygwin PostgreSQL is OK, but I'm not completely sure...

Is there anything else that you would like me to try?

Thanks,
Jason

Tom,

I forgot to mention in my last email that I could not compile the
latest PostgreSQL CVS under Cygwin without the attached (hacky) patch.
Does PostgreSQL CVS (i.e., libpq++) compile cleanly with gcc 2.95.2 under
other platforms? If so, then I will try to pursue this issue properly.

Thanks,
Jason

Jason Tishler <jason(at)tishler(dot)net> writes:
> - static PGSTD string IntToString(int);
> + PGSTD string IntToString(int);

This one is news to me. Please file a bug report about it. I have no
idea if that's the correct patch, though.

regards, tom lane

Jason Tishler <jason(at)tishler(dot)net> writes:
> I just built the latest PostgreSQL CVS and ran it against essentially
> the latest Cygwin CVS. make check failed with many connection refused
> false positives. Previously, I would only get these occasionally. Recall
> that Windows NT 4.0 Workstation and 2000 Professional only have a backlog
> size of 5. Can the above mentioned changes be the cause of the increased
> connection refused failures?

Hmm. I do not think so. The worrisome possibility is that our earlier
changes that make the postmaster fork() first and authenticate later
might be hurting performance, rather than helping it, at least on
Windows. But it's difficult to see why. Successful connections must
do a fork() sooner or later, so how could there be any net loss of
performance?

What authentication protocol are you using in this test?

> Additionally, I had (test) misc failures, but I believe that is due to the
> other failures? Is that assessment correct?

Quite a few of the tests are dependent on data inserted by earlier
tests, so I wouldn't worry too much about failures occurring after the
first connection-refused. You could look at the detail diffs and verify
that they look like missing data or missing tables.

> With the serial schedule, all tests passed except for random. Normally,
> I wouldn't worry, but random failed every time I ran either version of
> the regression test except for once. Does this indicate a problem?

I doubt it.

regards, tom lane

Tom,

On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> Jason Tishler <jason(at)tishler(dot)net> writes:
> > - static PGSTD string IntToString(int);
> > + PGSTD string IntToString(int);
>
> This one is news to me. Please file a bug report about it.

I just converted an old Windows NT 4.0 machine to Linux. I will do
a build there before submitting a bug report (if necessary). If it is
a Cygwin thing, then...

> I have no idea if that's the correct patch, though.

Agreed, I was just trying to get the build to finish so I could run the
regression test.

..I will try to come up with the correct patch.

Jason

Tom,

On Thu, Aug 16, 2001 at 07:23:16PM -0400, Tom Lane wrote:
> Jason Tishler <jason(at)tishler(dot)net> writes:
> > Can the above mentioned changes be the cause of the increased
> > connection refused failures?
>
> Hmm. I do not think so. The worrisome possibility is that our earlier
> changes that make the postmaster fork() first and authenticate later
> might be hurting performance, rather than helping it, at least on
> Windows. But it's difficult to see why. Successful connections must
> do a fork() sooner or later, so how could there be any net loss of
> performance?

From the PostgreSQL side, I don't see how either. But, maybe the latest
Cygwin is slower which is making the backend slower? Another possibility,
is that the Cygwin DLL that I'm using has vfork turned on, so maybe the
tests (i.e., the frontends) are being started faster than before?

I suggest that Terry Carlin rerun his benchmark suite on PostgreSQL
CVS running under Cygwin's most recent snapshot to see if he is getting
connection refused failures too.

> What authentication protocol are you using in this test?

I presume nothing (i.e., trust) or whatever is the default. Remember,
I'm just doing a "make check".

> > Additionally, I had (test) misc failures, but I believe that is due to the
> > other failures? Is that assessment correct?
>
> Quite a few of the tests are dependent on data inserted by earlier
> tests, so I wouldn't worry too much about failures occurring after the
> first connection-refused. You could look at the detail diffs and verify
> that they look like missing data or missing tables.

The above describes what I'm seeing in the diffs so I will ignore the
misc failures.

Thanks,
Jason

Tom,

On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> Jason Tishler <jason(at)tishler(dot)net> writes:
> > - static PGSTD string IntToString(int);
> > + PGSTD string IntToString(int);
>
> This one is news to me. Please file a bug report about it. I have no
> idea if that's the correct patch, though.

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.

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?

Thanks,
Jason

Jason Tishler <jason(at)tishler(dot)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?
Is it meaningful to do so on Cygwin (as opposed to bare WIN32)?

> 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.

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.

regards, tom lane

Tom,

On Tue, Aug 21, 2001 at 01:39:45PM -0400, Tom Lane wrote:
> Jason Tishler <jason(at)tishler(dot)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

OK, I just applied a libpq SOCK_STRERROR() patch for Win98. Would
people please try that and let us know how it works.

Not sure if this addresses the problems below.

> Tom,
>
> On Tue, Aug 21, 2001 at 01:39:45PM -0400, Tom Lane wrote:
> > Jason Tishler <jason(at)tishler(dot)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
>

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

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

> Tom,
>
> On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> > Jason Tishler <jason(at)tishler(dot)net> writes:
> > > - static PGSTD string IntToString(int);
> > > + PGSTD string IntToString(int);
> >
> > This one is news to me. Please file a bug report about it. I have no
> > idea if that's the correct patch, though.
>
> 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.
>
> 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?
>
> Thanks,
> Jason
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

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

I have already applied this fix:

revision 1.12
date: 2001/07/11 22:12:43; author: momjian; state: Exp; lines: +2 -2
Libpq++ fixes for Win32 compile.

Christian Ullrich

> Tom,
>
> On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> > Jason Tishler <jason(at)tishler(dot)net> writes:
> > > - static PGSTD string IntToString(int);
> > > + PGSTD string IntToString(int);
> >
> > This one is news to me. Please file a bug report about it. I have no
> > idea if that's the correct patch, though.
>
> 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.
>
> 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?
>
> Thanks,
> Jason
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

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

> 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.
>
> 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?

OK, have we resolved what should be in pgconnection.h?

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

Bruce,

On Fri, Aug 24, 2001 at 12:52:54PM -0400, Bruce Momjian wrote:
> > 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.
> >
> > 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?
>
> OK, have we resolved what should be in pgconnection.h?

I just did a cvs update to try again to verify whether or not the
Win32 libpq++ will build without the DLLIMPORT in pgconnection.h.

Unfortunately, I still cannot build even the Win32 libpq. See the
first attachment for my nmake output. Does the latest CVS really build
under MSVC++? Seems like md5.c is missing from win32.mak...

BTW, jdbc does not seem to build anymore either. See the second
attachment.

Thanks,
Jason

> Bruce,
>
> On Fri, Aug 24, 2001 at 12:52:54PM -0400, Bruce Momjian wrote:
> > > 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.
> > >
> > > 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?
> >
> > OK, have we resolved what should be in pgconnection.h?
>
> I just did a cvs update to try again to verify whether or not the
> Win32 libpq++ will build without the DLLIMPORT in pgconnection.h.
>
> Unfortunately, I still cannot build even the Win32 libpq. See the
> first attachment for my nmake output. Does the latest CVS really build
> under MSVC++? Seems like md5.c is missing from win32.mak...

OK, I just added md5.c to Win32.mak. This brings up another question.
dllist.c and md5.c are 'ln -s' from their homes to libpq directory,
while of course for win32.make we access them in their original
locations. Is there any reason to symlink them rather than just
refering to them in their original locations?

>
> BTW, jdbc does not seem to build anymore either. See the second
> attachment.

Yep, I threw out an email to the jdbc list an hour ago.

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

Can someone research this and figure out what the proper solution for
this is? Seems we are going around in circles if we keep
adding/removing DLLIMPORT.

>
> On Thu, Aug 16, 2001 at 03:07:10PM -0400, Tom Lane wrote:
> > Jason Tishler <jason(at)tishler(dot)net> writes:
> > > - static PGSTD string IntToString(int);
> > > + PGSTD string IntToString(int);
> >
> > This one is news to me. Please file a bug report about it. I have no
> > idea if that's the correct patch, though.
>
> 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. [ Removal of DLLIMPORT ]
>
> 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?
>
> Thanks,
> Jason
>

[ Attachment, skipping... ]

[ Attachment, skipping... ]

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

Bruce,

On Sat, Aug 25, 2001 at 08:15:45PM -0400, Bruce Momjian wrote:
> Can someone research this and figure out what the proper solution for
> this is? Seems we are going around in circles if we keep
> adding/removing DLLIMPORT.

I believe that the attached patch is the correct solution -- I apologize
for the gyrations. With the attached patch, Cygwin libpq++ builds
cleanly again. The root cause was that DLLIMPORT was defaulting to
__declspec(dllimport) since BUILDING_DLL was *not* defined when building
the libpq++ DLL.

Unfortunately, to test my patch requires changing the following makefile:

src/interfaces/libpq++/examples/Makefile

and the #includes in all of the *.cc to build against the source tree
instead of the following hardcoded installation directory structure:

/usr/local/pgsql

I was able to manually build

src/interfaces/libpq++/examples/testlibpq0.exe

against my Cygwin libpq++ without errors. However, I have not tried to
actually test testlibpq0.exe.

Is this sufficient? Or, do you want me to clean up libpq++/examples too?
(Or, is it silly to even ask? :,)) Let me know how you want to proceed and
I will submit a patch to pgsql-patches.

Thanks,
Jason

Frankly, I have no idea what this stuff needs to get it to work. I will
put this in the patch queue and please send over whatever else you think
will help.

The girations are fine. This is the nature of porting.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

> Bruce,
>
> On Sat, Aug 25, 2001 at 08:15:45PM -0400, Bruce Momjian wrote:
> > Can someone research this and figure out what the proper solution for
> > this is? Seems we are going around in circles if we keep
> > adding/removing DLLIMPORT.
>
> I believe that the attached patch is the correct solution -- I apologize
> for the gyrations. With the attached patch, Cygwin libpq++ builds
> cleanly again. The root cause was that DLLIMPORT was defaulting to
> __declspec(dllimport) since BUILDING_DLL was *not* defined when building
> the libpq++ DLL.
>
> Unfortunately, to test my patch requires changing the following makefile:
>
> src/interfaces/libpq++/examples/Makefile
>
> and the #includes in all of the *.cc to build against the source tree
> instead of the following hardcoded installation directory structure:
>
> /usr/local/pgsql
>
> I was able to manually build
>
> src/interfaces/libpq++/examples/testlibpq0.exe
>
> against my Cygwin libpq++ without errors. However, I have not tried to
> actually test testlibpq0.exe.
>
> Is this sufficient? Or, do you want me to clean up libpq++/examples too?
> (Or, is it silly to even ask? :,)) Let me know how you want to proceed and
> I will submit a patch to pgsql-patches.
>
> Thanks,
> Jason

[ Attachment, skipping... ]

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

Bruce,

On Fri, Aug 24, 2001 at 11:01:09PM -0400, Bruce Momjian wrote:
> This brings up another question.
> dllist.c and md5.c are 'ln -s' from their homes to libpq directory,
> while of course for win32.make we access them in their original
> locations. Is there any reason to symlink them rather than just
> refering to them in their original locations?

Sorry, I don't feel qualified to answer the above. How about Peter E?

Jason

Bruce,

On Sat, Aug 25, 2001 at 11:09:58PM -0400, Bruce Momjian wrote:
> Frankly, I have no idea what this stuff needs to get it to work. I will
> put this in the patch queue and please send over whatever else you think
> will help.
>
> [snip]
>
> > Unfortunately, to test my patch requires changing the following makefile:
> >
> > src/interfaces/libpq++/examples/Makefile
> >
> > and the #includes in all of the *.cc to build against the source tree
> > instead of the following hardcoded installation directory structure:
> >
> > /usr/local/pgsql
> >
> > I was able to manually build
> >
> > src/interfaces/libpq++/examples/testlibpq0.exe
> >
> > against my Cygwin libpq++ without errors. However, I have not tried to
> > actually test testlibpq0.exe.
> >
> > Is this sufficient?

I just tested testlibpq0.exe and it functioned as expected, so I am very
confident of my latest patch. Additionally, it should not affect any
platform (including Win32) except for Cygwin.

> > Or, do you want me to clean up libpq++/examples too?
> > (Or, is it silly to even ask? :,)) Let me know how you want to proceed and
> > I will submit a patch to pgsql-patches.

Sorry, but I'm going to punt on the above. libpq++/examples really,
really wants to build against an installation tree instead of a source
tree.

Jason

Patch applied. Thanks. Let me know if you have more patches to be
applied.

> Bruce,
>
> On Sat, Aug 25, 2001 at 08:15:45PM -0400, Bruce Momjian wrote:
> > Can someone research this and figure out what the proper solution for
> > this is? Seems we are going around in circles if we keep
> > adding/removing DLLIMPORT.
>
> I believe that the attached patch is the correct solution -- I apologize
> for the gyrations. With the attached patch, Cygwin libpq++ builds
> cleanly again. The root cause was that DLLIMPORT was defaulting to
> __declspec(dllimport) since BUILDING_DLL was *not* defined when building
> the libpq++ DLL.
>
> Unfortunately, to test my patch requires changing the following makefile:
>
> src/interfaces/libpq++/examples/Makefile
>
> and the #includes in all of the *.cc to build against the source tree
> instead of the following hardcoded installation directory structure:
>
> /usr/local/pgsql
>
> I was able to manually build
>
> src/interfaces/libpq++/examples/testlibpq0.exe
>
> against my Cygwin libpq++ without errors. However, I have not tried to
> actually test testlibpq0.exe.
>
> Is this sufficient? Or, do you want me to clean up libpq++/examples too?
> (Or, is it silly to even ask? :,)) Let me know how you want to proceed and
> I will submit a patch to pgsql-patches.
>
> Thanks,
> Jason

[ Attachment, skipping... ]

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

Bruce,

On Wed, Sep 05, 2001 at 10:59:55PM -0400, Bruce Momjian wrote:
> Patch applied. Thanks.

You are welcome.

> Let me know if you have more patches to be applied.

I currently have no Cygwin specific code patches queued up. However, I
still owe you a FAQ_MSWIN documentation patch.

Thanks,
Jason