Re: Cygwin PostgreSQL CVS Patch

Bruce,

On Fri, Dec 29, 2000 at 02:06:52PM -0500, Bruce Momjian wrote:
> Can you download the current snapshot and give it a try?

I just verified that the current snapshot:

ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz

with a time stamp of:

Fri Dec 29 09:03:00 2000

has this problem corrected.

Unfortunately, I found some more Cygwin build issues. I guess that it
is time to make another patch...

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> Unfortunately, I found some more Cygwin build issues. I guess that it
> is time to make another patch...

No time like the present ;-)

We are pointing for a 7.1beta2 release towards the end of next week.
If you can send patches in the next few days it'd be very timely...

regards, tom lane

Tom,

On Fri, Dec 29, 2000 at 11:58:16PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > Unfortunately, I found some more Cygwin build issues. I guess that it
> > is time to make another patch...
>
> No time like the present ;-)
>
> We are pointing for a 7.1beta2 release towards the end of next week.
> If you can send patches in the next few days it'd be very timely...

See attached for ChangeLog and patch. The instructions to apply the
patch is as follows:

$ tar -xzvf postgresql-snapshot.tar.gz
$ cd postgresql-snapshot
$ patch -p1 <Cygwin-1.1.7-PostgreSQL-20001229.patch

Note that I ran the regression tests and all 76 test passed.

Unfortunately, I was bitten by the pq.dll not in the PATH problem again --
shame on me. I should have sent in a patch for this before and I will
do so shortly. Due to the impending release, I don't want to hold up
the Cygwin (compilation) patch.

BTW, I was doing the builds and regression testing on my machine at
work via ssh so I didn't see Windows pop up its standard dialog until
after I VNC-ed in. Hence, when the regression test initially "hung,"
it became a real head banger there for a moment...

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> --- postgresql-20001229.orig/src/backend/utils/mmgr/mcxt.c Tue Aug 22 03:00:13 2000
> +++ postgresql-20001229/src/backend/utils/mmgr/mcxt.c Fri Dec 29 23:46:31 2000
> @@ -45,7 +45,7 @@ MemoryContext PostmasterContext = NULL;
> MemoryContext CacheMemoryContext = NULL;
> MemoryContext QueryContext = NULL;
> MemoryContext TopTransactionContext = NULL;
> -MemoryContext TransactionCommandContext = NULL;
> +DLLIMPORT MemoryContext TransactionCommandContext = NULL;

These changes look fine as far as they go, but if you think
TransactionCommandContext needs to be DLLIMPORT, why not the other
global context variables, too? What led you to mark it DLLIMPORT
anyway?

regards, tom lane

Tom,

On Sat, Dec 30, 2000 at 10:56:43PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > --- postgresql-20001229.orig/src/backend/utils/mmgr/mcxt.c Tue Aug 22 03:00:13 2000
> > +++ postgresql-20001229/src/backend/utils/mmgr/mcxt.c Fri Dec 29 23:46:31 2000
> > @@ -45,7 +45,7 @@ MemoryContext PostmasterContext = NULL;
> > MemoryContext CacheMemoryContext = NULL;
> > MemoryContext QueryContext = NULL;
> > MemoryContext TopTransactionContext = NULL;
> > -MemoryContext TransactionCommandContext = NULL;
> > +DLLIMPORT MemoryContext TransactionCommandContext = NULL;
>
> These changes look fine as far as they go, but if you think
> TransactionCommandContext needs to be DLLIMPORT, why not the other
> global context variables, too?

I took the minimalist approach -- meaning that I only made the minimum
number of changes necessary to get PostgreSQL to compile cleanly under
Cygwin. You are correct, the other global context variables should
also be marked DLLIMPORT. There are probably other global variables
that should be marked too.

The completeness approach would DLLIMPORT "everything" (similar to
the way that Python uses DL_EXPORT), but that would be a lot of source
code changes...

> What led you to mark it DLLIMPORT anyway?

I marked TransactionCommandContext as DLLIMPORT to get plpgsql.dll to
link without unresolved symbol errors.

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> Sat Dec 30 21:13:30 2000 Jason Tishler <jt(at)dothill(dot)com>
>
> * src/backend/utils/error/elog.c: Add conditional compilation to deal
> with sys_nerr/_sys_nerr inconsistencies.
> * src/backend/utils/error/exc.c: Ditto.

This is the wrong place. You should look into src/include/port/win.h to
fix this.

> * src/utils/dllinit.c: Update to be consistent with Cygwin Net Release.

Will this break old releases of Cygwin?

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
>> These changes look fine as far as they go, but if you think
>> TransactionCommandContext needs to be DLLIMPORT, why not the other
>> global context variables, too?

> I took the minimalist approach -- meaning that I only made the minimum
> number of changes necessary to get PostgreSQL to compile cleanly under
> Cygwin. You are correct, the other global context variables should
> also be marked DLLIMPORT. There are probably other global variables
> that should be marked too.

> The completeness approach would DLLIMPORT "everything" (similar to
> the way that Python uses DL_EXPORT), but that would be a lot of source
> code changes...

Seems like that's heading in the wrong direction. Isn't there a
compiler switch or something we could give to make ALL global vars be
automatically marked DLLIMPORT? That's generally how it works on Unix
platforms (for example, on HPUX the -E linker switch makes these symbols
available to dynamically linked shlibs). I don't really like the idea
of cluttering the source code for the benefit of one platform...

regards, tom lane

On Sun, Dec 31, 2000 at 12:12:18AM -0500, Jason Tishler wrote:
> > What led you to mark it DLLIMPORT anyway?
>
> I marked TransactionCommandContext as DLLIMPORT to get plpgsql.dll to
> link without unresolved symbol errors.

Please remove the src/backend/utils/mmgr/mcxt.c hunk from my patch -- it
is unnecessary. I was mislead by an unnecessary DLLIMPORT located a few
lines above my erroneous change to mcxt.c. Specifically, DLLIMPORT can
be also safely removed from:

DLLIMPORT MemoryContext CurrentMemoryContext = NULL;

The DLLIMPORT is only necessary in the corresponding header files (i.e.,
src/include/utils/memutils.h and src/include/utils/palloc.h).

Otherwise, you can wait for me to redo the patch once the remaining issues
settle down...

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Tom,

On Sun, Dec 31, 2000 at 05:53:09PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> >> These changes look fine as far as they go, but if you think
> >> TransactionCommandContext needs to be DLLIMPORT, why not the other
> >> global context variables, too?
>
> > I took the minimalist approach -- meaning that I only made the minimum
> > number of changes necessary to get PostgreSQL to compile cleanly under
> > Cygwin. You are correct, the other global context variables should
> > also be marked DLLIMPORT. There are probably other global variables
> > that should be marked too.
>
> > The completeness approach would DLLIMPORT "everything" (similar to
> > the way that Python uses DL_EXPORT), but that would be a lot of source
> > code changes...
>
> Seems like that's heading in the wrong direction. Isn't there a
> compiler switch or something we could give to make ALL global vars be
> automatically marked DLLIMPORT? That's generally how it works on Unix
> platforms (for example, on HPUX the -E linker switch makes these symbols
> available to dynamically linked shlibs).

There is a way and the PostgreSQL build is already taking advantage of
it:

dlltool --export-all --output-def postgres.def access/SUBSYS.o ...

However, there is a downside to the above. Now all functions and global
variables are exported from postgres.exe -- not just the ones that make
sense. This is why the Python approach may be considered "better."

Unfortunately, the above still does not mitigate the need for marking
global variables DLLIMPORT in their corresponding header files to
prevent unresolved linker errors by clients of libpostgres.a.

> I don't really like the idea of cluttering the source code for the
> benefit of one platform...

Agreed.

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Peter,

On Sun, Dec 31, 2000 at 01:12:59PM +0100, Peter Eisentraut wrote:
> Jason Tishler writes:
>
> > Sat Dec 30 21:13:30 2000 Jason Tishler <jt(at)dothill(dot)com>
> >
> > * src/backend/utils/error/elog.c: Add conditional compilation to deal
> > with sys_nerr/_sys_nerr inconsistencies.
> > * src/backend/utils/error/exc.c: Ditto.
>
> This is the wrong place.

Sorry, but I'm not that intimate with the PostgreSQL code so when I saw
the following in elog.c and exc.c:

#ifdef __CYGWIN__
# define sys_nerr _sys_nerr
#endif
extern int sys_nerr;

I thought that it was reasonable to change it to:

#ifdef __CYGWIN__
# define sys_nerr _sys_nerr
#else
extern int sys_nerr;
#endif

Note that if the following line:

extern int sys_nerr;

is not guarded from Cygiwn, then one will always get an unresolved linker
error because of a missing " __declspec(dllimport)".

> You should look into src/include/port/win.h to fix this.

How is this file suppose to be used? When I do a find, I get the
following:

$ find . -type f | xargs fgrep win.h
./backend/port/dynloader/darwin.h:/* $Header: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/darwin.h,v 1.3 2000/12/11 00:49:54 tgl Exp $ */
./backend/port/dynloader/win.c: * see win.h
./backend/port/dynloader/win.h: * win.h
./backend/port/dynloader/win.h: * win.h,v 1.2 1995/03/17 06:40:18 andrew Exp

Hence, no source file is currently including it.

> > * src/utils/dllinit.c: Update to be consistent with Cygwin Net Release.
>
> Will this break old releases of Cygwin?

I don't know since I don't have b20.1 or older lying around anymore --
but my guess is yes. However, without this change PostgreSQL does *not*
build OOTB with the current Cygwin release.

Note that this file is no longer needed with current Cygwin releases.
Cygwin provides its own "DllMain" now. May be a compromise would be to
have make check the Cygwin version and eliminate dllinit.c from the
build if it is not necessary. I am willing to submit such a patch if it
was deemed reasonable.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corporation Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> > > * src/backend/utils/error/elog.c: Add conditional compilation to deal
> > > with sys_nerr/_sys_nerr inconsistencies.
> > > * src/backend/utils/error/exc.c: Ditto.
> >
> > This is the wrong place.
>
> Sorry, but I'm not that intimate with the PostgreSQL code so when I saw
> the following in elog.c and exc.c:
>
> #ifdef __CYGWIN__
> # define sys_nerr _sys_nerr
> #endif
> extern int sys_nerr;

I guess there were some people before you that weren't that intimate with
the code either. ;-)

> I thought that it was reasonable to change it to:
>
> #ifdef __CYGWIN__
> # define sys_nerr _sys_nerr
> #else
> extern int sys_nerr;
> #endif

I think if Cygwin's strerror() copes with out-of-range errno's, then we
can just leave of the whole business completely.

> > You should look into src/include/port/win.h to fix this.
>
> How is this file suppose to be used? When I do a find, I get the
> following:

> Hence, no source file is currently including it.

src/include/port/anything.h is symlinked to src/include/port.h when you
run configure. port.h is included by config.h, which is included by c.h,
which is included by postgres.h, which is included by just about
everything. (Note to self: Are that many levels really necessary?)

> > > * src/utils/dllinit.c: Update to be consistent with Cygwin Net Release.
> >
> > Will this break old releases of Cygwin?
>
> I don't know since I don't have b20.1 or older lying around anymore --
> but my guess is yes. However, without this change PostgreSQL does *not*
> build OOTB with the current Cygwin release.

Well, it's not like I really care, as I obviously don't use Cygwin, but
dropping support for old OS version just because new ones came out is not
that cool, unless you can make a really good argument that no one in their
right mind would use that old version anymore.

> Note that this file is no longer needed with current Cygwin releases.
> Cygwin provides its own "DllMain" now. May be a compromise would be to
> have make check the Cygwin version and eliminate dllinit.c from the
> build if it is not necessary. I am willing to submit such a patch if it
> was deemed reasonable.

Sounds great to me. Maybe the CYGWIN_VERSION_API_MAJOR/MINOR symbols
could be used to #ifdef out the entire dllinit.c if not needed? (A more
"correct" approach would probably be to check for the existance of
DllMain, but I'm not sure if you/we are up to that at this point.)

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Peter Eisentraut writes:
> I think if Cygwin's strerror() copes with out-of-range errno's,
> then we can just leave of the whole business completely.

It does.

> Well, it's not like I really care, as I obviously don't use Cygwin,
> but dropping support for old OS version just because new ones came
> out is not that cool, unless you can make a really good argument
> that no one in their right mind would use that old version anymore.

Old versions of Cygwin can be made to work but it is just more
effort. A lot of the items to be done are no longer needed. For
example, if you use B20.1 then you need to install your own copy of
libcrypt. The current Cygwin has it as standard.

If PostgreSQL 6 users hit known problems, do we not recommend
upgrading to v7 rather than making patches against v6? The latter can
be done but it is not the preferred choice.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete(dot)forman(at)westerngeco(dot)com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.

Peter,

On Tue, Jan 02, 2001 at 06:00:26PM +0100, Peter Eisentraut wrote:
> I think if Cygwin's strerror() copes with out-of-range errno's, then we
> can just leave of the whole business completely.

On Wed, Jan 03, 2001 at 08:46:58AM +0000, Pete Forman wrote:
> Peter Eisentraut writes:
> > I think if Cygwin's strerror() copes with out-of-range errno's,
> > then we can just leave of the whole business completely.
>
> It does.

Given the above, I'm willing to rip out the sys_nerr stuff in elog.c and
exc.c but I'm afraid of breaking other platforms. Please advise.

> src/include/port/anything.h is symlinked to src/include/port.h when you
> run configure. port.h is included by config.h, which is included by c.h,
> which is included by postgres.h, which is included by just about
> everything. (Note to self: Are that many levels really necessary?)

I presume that you really meant "os.h" instead of "port.h" above.

> > > > * src/utils/dllinit.c: Update to be consistent with Cygwin Net Release.
> > >
> > > Will this break old releases of Cygwin?
> >
> > I don't know since I don't have b20.1 or older lying around anymore --
> > but my guess is yes. However, without this change PostgreSQL does *not*
> > build OOTB with the current Cygwin release.
>
> Well, it's not like I really care, as I obviously don't use Cygwin, but
> dropping support for old OS version just because new ones came out is not
> that cool, unless you can make a really good argument that no one in their
> right mind would use that old version anymore.

I will reiterate that Cygnus (a.k.a Red Hat) has stated that they no
longer support b20.1 anymore. They are actually seeking out mirrors
with the old releases and requesting that they be deleted. It will
become harder and harder to find b20.1 soon...

> > Note that this file is no longer needed with current Cygwin releases.
> > Cygwin provides its own "DllMain" now. May be a compromise would be to
> > have make check the Cygwin version and eliminate dllinit.c from the
> > build if it is not necessary. I am willing to submit such a patch if it
> > was deemed reasonable.
>
> Sounds great to me. Maybe the CYGWIN_VERSION_API_MAJOR/MINOR symbols
> could be used to #ifdef out the entire dllinit.c if not needed? (A more
> "correct" approach would probably be to check for the existance of
> DllMain, but I'm not sure if you/we are up to that at this point.)

Can I assume that dllinit.c is only used by Cygwin (i.e, not by straight
Win32)? If so, then I can surround the contents with:

#include <cygwin/version.h>
#if CYGWIN_VERSION_DLL_MAJOR < 1001
...
#endif /* CYGWIN_VERSION_DLL_MAJOR */

Otherwise, this part of the patch is going to get ugly.

I will resubmit my patch after the above issues are resolved.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Tom,

On Fri, Dec 29, 2000 at 11:58:16PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > Unfortunately, I found some more Cygwin build issues. I guess that
> > it
> > is time to make another patch...
>
> No time like the present ;-)
>
> We are pointing for a 7.1beta2 release towards the end of next week.
> If you can send patches in the next few days it'd be very timely...

On Wed, Jan 03, 2001 at 03:34:50PM -0500, Jason Tishler wrote:
> I will resubmit my patch after the above issues are resolved.

Unfortunately, I have not received any more feedback regarding the
Cygwin patch issues. Should I submit my latest patch anyway? Did I
miss the 7.1beta2 release?

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> > Seems like that's heading in the wrong direction. Isn't there a
> > compiler switch or something we could give to make ALL global vars be
> > automatically marked DLLIMPORT? That's generally how it works on Unix
> > platforms (for example, on HPUX the -E linker switch makes these symbols
> > available to dynamically linked shlibs).
>
> There is a way and the PostgreSQL build is already taking advantage of
> it:
>
> dlltool --export-all --output-def postgres.def access/SUBSYS.o ...
>
> However, there is a downside to the above. Now all functions and global
> variables are exported from postgres.exe -- not just the ones that make
> sense.

That's the same across all platforms though. "Sense" is something the
user can find out about.

> Unfortunately, the above still does not mitigate the need for marking
> global variables DLLIMPORT in their corresponding header files to
> prevent unresolved linker errors by clients of libpostgres.a.

What's the point of --export-all then?

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
>> I will resubmit my patch after the above issues are resolved.

> Unfortunately, I have not received any more feedback regarding the
> Cygwin patch issues. Should I submit my latest patch anyway? Did I
> miss the 7.1beta2 release?

I think you've missed the window for the beta3 (nee beta2) release,
but please do send in the patch anyway as soon as you're happy with it.

regards, tom lane

Peter,

On Tue, Jan 09, 2001 at 06:59:54PM +0100, Peter Eisentraut wrote:
> Jason Tishler writes:
> > Unfortunately, the above still does not mitigate the need for marking
> > global variables DLLIMPORT in their corresponding header files to
> > prevent unresolved linker errors by clients of libpostgres.a.
>
> What's the point of --export-all then?

The --export-all option is very helpful for the DLL provider, but
unfortunately nothing analogous exists for the DLL consumer. Welcome
to the wonderful world of Windows!

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Tom,

On Tue, Jan 09, 2001 at 01:05:13PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> >> I will resubmit my patch after the above issues are resolved.
>
> > Unfortunately, I have not received any more feedback regarding the
> > Cygwin patch issues. Should I submit my latest patch anyway? Did I
> > miss the 7.1beta2 release?
>
> I think you've missed the window for the beta3 (nee beta2) release,
> but please do send in the patch anyway as soon as you're happy with it.

Will do. I was happy with it last week -- the issue is will others be
happy with it too...

BTW, is the release schedule documented anywhere? I tried to find this
information on the web site but have not had any luck.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> BTW, is the release schedule documented anywhere?

Schedule? There is no schedule. We'll release when we think it's ready.

Possibly around the end of the month, but don't hold me to that.

regards, tom lane

Jason Tishler writes:

> Unfortunately, I have not received any more feedback regarding the
> Cygwin patch issues. Should I submit my latest patch anyway? Did I
> miss the 7.1beta2 release?

I've already fixed the sys_nerr and removed -L$(libdir), as per your
previous patch. I think that leaves you with adding DLLIMPORT at the
appropriate places and doing something about dllinit.c. I'm not sure what
the outcome of the discussion about the latter was, but I think using the
API version number as a conditional was thought to be feasible.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Peter,

On Tue, Jan 09, 2001 at 09:06:10PM +0100, Peter Eisentraut wrote:
> Jason Tishler writes:
>
> > Unfortunately, I have not received any more feedback regarding the
> > Cygwin patch issues. Should I submit my latest patch anyway? Did I
> > miss the 7.1beta2 release?
>
> I've already fixed the sys_nerr and removed -L$(libdir), as per your
> previous patch. I think that leaves you with adding DLLIMPORT at the
> appropriate places and doing something about dllinit.c. I'm not sure what
> the outcome of the discussion about the latter was, but I think using the
> API version number as a conditional was thought to be feasible.

I'm working against CVS now to provide the remainder of the Cygwin patch.
Why did you remove the following from src/include/port/win.h?

#if (CYGWIN_VERSION_API_MAJOR >= 0) && (CYGWIN_VERSION_API_MINOR >= 8)
#define sys_nerr _sys_nerr
#endif

This definitely breaks Cygwin.

I guess that the discussion continues... :,)

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> Why did you remove the following from src/include/port/win.h?
> #if (CYGWIN_VERSION_API_MAJOR >= 0) && (CYGWIN_VERSION_API_MINOR >= 8)
> #define sys_nerr _sys_nerr
> #endif
> This definitely breaks Cygwin.

Er, why should it? With the code as it stands, configure should decide
that Cygwin doesn't HAVE_SYS_NERR, and so nothing will reference
sys_nerr.

regards, tom lane

On Tue, Jan 09, 2001 at 04:34:57PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > Why did you remove the following from src/include/port/win.h?
> > #if (CYGWIN_VERSION_API_MAJOR >= 0) && (CYGWIN_VERSION_API_MINOR >= 8)
> > #define sys_nerr _sys_nerr
> > #endif
> > This definitely breaks Cygwin.
>
> Er, why should it? With the code as it stands, configure should decide
> that Cygwin doesn't HAVE_SYS_NERR, and so nothing will reference
> sys_nerr.

Unfortunately, the above is not true:

$ configure
...
checking for sys_nerr... yes
...

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Peter,

On Tue, Jan 09, 2001 at 05:55:39PM -0500, Jason Tishler wrote:
> On Tue, Jan 09, 2001 at 04:34:57PM -0500, Tom Lane wrote:
> > Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > > Why did you remove the following from src/include/port/win.h?
> > > #if (CYGWIN_VERSION_API_MAJOR >= 0) && (CYGWIN_VERSION_API_MINOR >= 8)
> > > #define sys_nerr _sys_nerr
> > > #endif
> > > This definitely breaks Cygwin.
> >
> > Er, why should it? With the code as it stands, configure should decide
> > that Cygwin doesn't HAVE_SYS_NERR, and so nothing will reference
> > sys_nerr.
>
> Unfortunately, the above is not true:
>
> $ configure
> ...
> checking for sys_nerr... yes
> ...

I have more details as to why the above is occurring.

Consider the following program, j.c, which is derived from the sys_nerr
test program in configure:

extern int sys_nerr;
int main() {
int x = sys_nerr;
; return 0; }

Now compile it with the same (relevant) options used by configure:

$ gcc -O2 -o j j.c

Now compile it without the -O2 option:

$ gcc -o j j.c
/tmp/ccf49pHw.o(.text+0xc):j.c: undefined reference to `sys_nerr'
collect2: ld returned 1 exit status

The problem is gcc -O2 is being too smart, optimizing away the reference
to sys_nerr.

So when configure compiles it's sys_nerr test program it compiles without
errors and returns 0 which fools configure into thinking that Cygwin has
sys_nerr.

Any ideas on what is the best way to solve this problem?

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
>> Er, why should it? With the code as it stands, configure should decide
>> that Cygwin doesn't HAVE_SYS_NERR, and so nothing will reference
>> sys_nerr.

> Unfortunately, the above is not true:

> $ configure
> ...
> checking for sys_nerr... yes

That's pretty darn interesting. The configure check looks bulletproof
to me:

[AC_TRY_LINK([extern int sys_nerr;],
[int x = sys_nerr;],

Would you poke into it and figure out how this is succeeding, if there's
not any sys_nerr variable exported from the C library?

regards, tom lane

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> extern int sys_nerr;
> int main() {
> int x = sys_nerr;
> ; return 0; }

> The problem is gcc -O2 is being too smart, optimizing away the reference
> to sys_nerr.

Oh, that's nasty. Try a test program like so:

extern int sys_nerr;
int my_nerr;
int main() {
my_nerr = sys_nerr;
return 0; }

I don't think gcc will try to optimize away an assignment to a global
variable.

regards, tom lane

Tom,

On Tue, Jan 09, 2001 at 06:37:31PM -0500, Tom Lane wrote:
> Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> > extern int sys_nerr;
> > int main() {
> > int x = sys_nerr;
> > ; return 0; }
>
> > The problem is gcc -O2 is being too smart, optimizing away the reference
> > to sys_nerr.
>
> Oh, that's nasty. Try a test program like so:
>
> extern int sys_nerr;
> int my_nerr;
> int main() {
> my_nerr = sys_nerr;
> return 0; }
>
> I don't think gcc will try to optimize away an assignment to a global
> variable.

You are correct -- the above program fails as expected.

Are you going to change config/c-library.m4 to generate the above
program instead?

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
>> I don't think gcc will try to optimize away an assignment to a global
>> variable.

> You are correct -- the above program fails as expected.

Oh, good.

> Are you going to change config/c-library.m4 to generate the above
> program instead?

This is Peter's turf, but I will take care of it if he doesn't get to it
soon. In the meantime, please work up a final Cygwin patch on the
assumption that configure will be fixed as above.

regards, tom lane

Tom,

On Tue, Jan 09, 2001 at 11:39:07PM -0500, Tom Lane wrote:
> This is Peter's turf, but I will take care of it if he doesn't get to it
> soon. In the meantime, please work up a final Cygwin patch on the
> assumption that configure will be fixed as above.

Will do.

I can develop and test the patch by just hand editing config.h to #undef
HAVE_SYS_NERR after configure has been run.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Tom,

On Tue, Jan 09, 2001 at 11:39:07PM -0500, Tom Lane wrote:
> This is Peter's turf, but I will take care of it if he doesn't get to it
> soon. In the meantime, please work up a final Cygwin patch on the
> assumption that configure will be fixed as above.

See attached for ChangeLog and patch. The instructions to apply the
patch is as follows:

$ cd pgsql # top of CVS working directory
$ # save Cygwin-1.1.7-PostgreSQL-CVS-2.patch to current directory
$ patch -p0 <Cygwin-1.1.7-PostgreSQL-CVS-2.patch

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Peter, any remaining objections, or does this look OK now?

regards, tom lane

Jason Tishler writes:

> Tom,
>
> On Tue, Jan 09, 2001 at 11:39:07PM -0500, Tom Lane wrote:
> > This is Peter's turf, but I will take care of it if he doesn't get to it
> > soon. In the meantime, please work up a final Cygwin patch on the
> > assumption that configure will be fixed as above.
>
> See attached for ChangeLog and patch. The instructions to apply the
> patch is as follows:

The Makefile.shlib patch looks like a hack to me to get the regression
tests to work. Surely you don't have to install *all* shared libraries
into bindir *and* libdir. Pick one or fix the regression test driver or
do something else.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Though I saw no email report, it seems this patch has been applied.

> Tom,
>
> On Tue, Jan 09, 2001 at 11:39:07PM -0500, Tom Lane wrote:
> > This is Peter's turf, but I will take care of it if he doesn't get to it
> > soon. In the meantime, please work up a final Cygwin patch on the
> > assumption that configure will be fixed as above.
>
> See attached for ChangeLog and patch. The instructions to apply the
> patch is as follows:
>
> $ cd pgsql # top of CVS working directory
> $ # save Cygwin-1.1.7-PostgreSQL-CVS-2.patch to current directory
> $ patch -p0 <Cygwin-1.1.7-PostgreSQL-CVS-2.patch
>
> Thanks,
> Jason
>
> --
> Jason Tishler
> Director, Software Engineering Phone: +1 (732) 264-8770 x235
> Dot Hill Systems Corp. Fax: +1 (732) 264-8798
> 82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
> Hazlet, NJ 07730 USA WWW: http://www.dothill.com

[ 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

Peter,

On Fri, Jan 12, 2001 at 12:54:07AM +0100, Peter Eisentraut wrote:
> > On Tue, Jan 09, 2001 at 11:39:07PM -0500, Tom Lane wrote:
> > > This is Peter's turf, but I will take care of it if he doesn't get to it
> > > soon. In the meantime, please work up a final Cygwin patch on the
> > > assumption that configure will be fixed as above.
> >
> > See attached for ChangeLog and patch. The instructions to apply the
> > patch is as follows:
>
> The Makefile.shlib patch looks like a hack to me to get the regression
> tests to work. Surely you don't have to install *all* shared libraries
> into bindir *and* libdir. Pick one or fix the regression test driver or
> do something else.

My reasons for installing the "shared" libraries, DLLs under Cygwin,
into bindir and libdir are as follows:

1. All of the DLLs except for plpgsql.dll need to be in the users
PATH, otherwise Windows cannot start applications that depend on them.
The canonical example is the regression test (really psql). However,
any app that is dependent on ecpg.dll, pgeasy.dll, pq.dll, or pq++.dll
will have this problem too. The only exception is plpgsql.dll which
needs to be in LD_LIBRARY_PATH since it is dlopen-ed into
postgres.exe, if appropriate.

2. I would prefer to use symlinks but that would require the real
files to be installed in bindir and symlinked back to libdir because
Windows does *not* understand Cygwin symlinks. Doing so would have
caused more significant changes to the makefiles which I don't believe
is desired for just one platform.

3. I continued to install the DLLs to libdir because I was concerned
that postgres.exe (or other executables) might be dlopen-ing them.
If so, then LD_LIBRARY_PATH would have to be set to a different
value on Cygwin than on other UNIX systems.

The only downside that I can see from installing to both bindir and
libdir is the possibility of the copies from getting out of sync and
wasted disk space. The wasted disk space is really not an issue since
the total size of the five stripped DLLs on 7.0.3 is ~250K.

I admit that there is a "hacky" aspect to the Makefile.shlib patch. I am
lucky that plpgsql.dll doesn't get installed to both bindir and libdir.
This is a desired side effect due to plpgsql.dll's install rule overriding
the standard one in Makefile.shlib.

Given more insight into my reasoning, will you reconsider and accept my
Makefile.shlib patch?

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> My reasons for installing the "shared" libraries, DLLs under Cygwin,
> into bindir and libdir are as follows:
>
> 1. All of the DLLs except for plpgsql.dll need to be in the users
> PATH, otherwise Windows cannot start applications that depend on them.

Okay, so you set your PATH to include libdir. No problem there.

> The canonical example is the regression test (really psql).

Okay, so we could change the regression test driver to set a PATH that
includes libdir. No problem there.

> However,
> any app that is dependent on ecpg.dll, pgeasy.dll, pq.dll, or pq++.dll
> will have this problem too. The only exception is plpgsql.dll which
> needs to be in LD_LIBRARY_PATH since it is dlopen-ed into
> postgres.exe, if appropriate.

So you set your LD_LIBRARY_PATH to include libdir as you always had to.
No problem there.

> 3. I continued to install the DLLs to libdir because I was concerned
> that postgres.exe (or other executables) might be dlopen-ing them.
> If so, then LD_LIBRARY_PATH would have to be set to a different
> value on Cygwin than on other UNIX systems.

On modern Unixes it is no longer necessary to set LD_LIBRARY_PATH at all
(and on those where it is the variable isn't necessarily called that), so
we're looking at platform-specific requirements anyway.

> Given more insight into my reasoning, will you reconsider and accept my
> Makefile.shlib patch?

I'd like to know what libtool does. Diverging from libtool behaviour will
get us into trouble in the future.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Peter,

On Fri, Jan 12, 2001 at 04:59:17PM +0100, Peter Eisentraut wrote:
> Jason Tishler writes:
> > The canonical example is the regression test (really psql).
>
> Okay, so we could change the regression test driver to set a PATH that
> includes libdir. No problem there.

See attached patch for the above.

> > Given more insight into my reasoning, will you reconsider and accept my
> > Makefile.shlib patch?
>
> I'd like to know what libtool does. Diverging from libtool behavior will
> get us into trouble in the future.

I don't know much about libtool so I can't help you here. However, I
agree completely with your assessment.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> > Okay, so we could change the regression test driver to set a PATH that
> > includes libdir. No problem there.
>
> See attached patch for the above.

Installed.

Another issue you might be interested in is that of Unix domain sockets.
I understand that they now exist in Cygwin, so you might want to refine
this snippet in src/include/config.h[.in]:

/*
* Define this if your operating system supports AF_UNIX family sockets.
*/
#if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
# define HAVE_UNIX_SOCKETS 1
#endif

And take a look at doc/FAQ_MSWIN, if you like, to see if it's up to date.

Many thanks.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Peter,

On Sat, Jan 13, 2001 at 04:37:31AM +0100, Peter Eisentraut wrote:
> Jason Tishler writes:
>
> > > Okay, so we could change the regression test driver to set a PATH that
> > > includes libdir. No problem there.
> >
> > See attached patch for the above.
>
> Installed.

Thanks. I meant to surround the Cygwin specific stuff with a case
statement but forgot -- thanks for cleaning up after me. Sigh...

> Another issue you might be interested in is that of Unix domain sockets.
> I understand that they now exist in Cygwin, so you might want to refine
> this snippet in src/include/config.h[.in]:
>
> /*
> * Define this if your operating system supports AF_UNIX family sockets.
> */
> #if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
> # define HAVE_UNIX_SOCKETS 1
> #endif
>
> And take a look at doc/FAQ_MSWIN, if you like, to see if it's up to date.

See attached patch and ChangeLog. This trivial patch enables UNIX
domain sockets for Cygwin. This version of Cygwin PostgreSQL still
passes all regression tests. However, there are two issues with
Cygwin's support of UNIX domain sockets:

1. psql (and other clients) with hang if postmaster is not running
and the socket file (e.g., /tmp/.s.PGSQL.5432) exists
2. Cygwin's AF_UNIX sockets are really implemented as AF_INET
sockets so they are inherently insecure. See the follow for more
details:

http://sources.redhat.com/ml/cygwin/2000-12/msg01058.html

The procedure to apply the patch is as follows:

$ cd pgsql
$ # save attached patch to current directory
$ patch -p0 <af_unix.patch

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> diff -u -r1.155 config.h.in
> --- src/include/config.h.in 2001/01/09 18:40:15 1.155
> +++ src/include/config.h.in 2001/01/16 14:20:10
> @@ -228,7 +228,7 @@
> /*
> * Define this if your operating system supports AF_UNIX family sockets.
> */
> -#if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
> +#if !defined(__QNX__) && !defined(__BEOS__)
> # define HAVE_UNIX_SOCKETS 1
> #endif

I could have figured as much ;-) but after we went through the trouble of
coping with old Cygwin's in dllinit.c we should do the same here. The
question is again how to do that.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Can someone tell me the status of this patch?

> Peter,
>
> On Sat, Jan 13, 2001 at 04:37:31AM +0100, Peter Eisentraut wrote:
> > Jason Tishler writes:
> >
> > > > Okay, so we could change the regression test driver to set a PATH that
> > > > includes libdir. No problem there.
> > >
> > > See attached patch for the above.
> >
> > Installed.
>
> Thanks. I meant to surround the Cygwin specific stuff with a case
> statement but forgot -- thanks for cleaning up after me. Sigh...
>
> > Another issue you might be interested in is that of Unix domain sockets.
> > I understand that they now exist in Cygwin, so you might want to refine
> > this snippet in src/include/config.h[.in]:
> >
> > /*
> > * Define this if your operating system supports AF_UNIX family sockets.
> > */
> > #if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
> > # define HAVE_UNIX_SOCKETS 1
> > #endif
> >
> > And take a look at doc/FAQ_MSWIN, if you like, to see if it's up to date.
>
> See attached patch and ChangeLog. This trivial patch enables UNIX
> domain sockets for Cygwin. This version of Cygwin PostgreSQL still
> passes all regression tests. However, there are two issues with
> Cygwin's support of UNIX domain sockets:
>
> 1. psql (and other clients) with hang if postmaster is not running
> and the socket file (e.g., /tmp/.s.PGSQL.5432) exists
> 2. Cygwin's AF_UNIX sockets are really implemented as AF_INET
> sockets so they are inherently insecure. See the follow for more
> details:
>
> http://sources.redhat.com/ml/cygwin/2000-12/msg01058.html
>
> The procedure to apply the patch is as follows:
>
> $ cd pgsql
> $ # save attached patch to current directory
> $ patch -p0 <af_unix.patch
>
> Thanks,
> Jason
>
> --
> Jason Tishler
> Director, Software Engineering Phone: +1 (732) 264-8770 x235
> Dot Hill Systems Corp. Fax: +1 (732) 264-8798
> 82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
> Hazlet, NJ 07730 USA WWW: http://www.dothill.com

[ 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 Wed, Jan 17, 2001 at 05:08:18PM -0500, Bruce Momjian wrote:
> Can someone tell me the status of this patch?

I believe all but the src/include/config.h.in part is acceptable to
Peter, but I would rather not speak for him.

Anyway, I have posted the following to the Cygwin list:

http://cygwin.com/ml/cygwin/2001-01/msg00844.html

Unfortunately, I have not received any replies yet.

Assuming that I don't get any feedback, I am going to submit a patch
based on the above tomorrow morning.

Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

On Tue, Jan 16, 2001 at 04:49:18PM +0100, Peter Eisentraut wrote:
> Jason Tishler writes:
>
> > diff -u -r1.155 config.h.in
> > --- src/include/config.h.in 2001/01/09 18:40:15 1.155
> > +++ src/include/config.h.in 2001/01/16 14:20:10
> > @@ -228,7 +228,7 @@
> > /*
> > * Define this if your operating system supports AF_UNIX family sockets.
> > */
> > -#if !defined(__CYGWIN__) && !defined(__QNX__) && !defined(__BEOS__)
> > +#if !defined(__QNX__) && !defined(__BEOS__)
> > # define HAVE_UNIX_SOCKETS 1
> > #endif
>
> I could have figured as much ;-) but after we went through the trouble of
> coping with old Cygwin's in dllinit.c we should do the same here. The
> question is again how to do that.

After seeing that config.h.in already included os.h, I thought that the
following was a reasonable way to improved the above to deal with b20.1
and the Net Release:

#if !(defined (__CYGWIN__) && CYGWIN_VERSION_DLL_MAJOR < 1001) && \
!defined(__QNX__) && !defined(__BEOS__)
# define HAVE_UNIX_SOCKETS 1
#endif

Unfortunately I didn't realize that os.h is included *after* the
AF_UNIX test, so the above will not work until cygwin/version.h is
included prior the test.

As I see it, I have two choices:

1. Add the following cruft right before the above:

#ifdef __CYGWIN__
#include <cygwin/version.h>
#endif

2. Move the including of os.h to somewhere before the above.

Any suggestions or guidance would be appreciated.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler <Jason(dot)Tishler(at)dothill(dot)com> writes:
> 1. Add the following cruft right before the above:

> #ifdef __CYGWIN__
> #include <cygwin/version.h>
> #endif

> 2. Move the including of os.h to somewhere before the above.

I don't like #2 since there may be (now or in the future) port header
files that depend on being able to override config.h choices.

A third alternative is to remove all mention of cygwin from the
test in config.h, allowing it to #define HAVE_UNIX_SOCKETS always,
and then in the cygwin os.h #undef it again if it's old cygwin.

regards, tom lane

Tom,

On Thu, Jan 18, 2001 at 01:03:18PM -0500, Tom Lane wrote:
> A third alternative is to remove all mention of cygwin from the
> test in config.h, allowing it to #define HAVE_UNIX_SOCKETS always,
> and then in the cygwin os.h #undef it again if it's old cygwin.

I like this approach best and I am going forward with it.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Peter,

On Tue, Jan 16, 2001 at 04:49:18PM +0100, Peter Eisentraut wrote:
> I could have figured as much ;-) but after we went through the trouble of
> coping with old Cygwin's in dllinit.c we should do the same here. The
> question is again how to do that.

See attached for another attempt. The only difference is the addition
of a src/include/port/win.h patch.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp. Fax: +1 (732) 264-8798
82 Bethany Road, Suite 7 Email: Jason(dot)Tishler(at)dothill(dot)com
Hazlet, NJ 07730 USA WWW: http://www.dothill.com

Jason Tishler writes:

> > I could have figured as much ;-) but after we went through the trouble of
> > coping with old Cygwin's in dllinit.c we should do the same here. The
> > question is again how to do that.
>
> See attached for another attempt. The only difference is the addition
> of a src/include/port/win.h patch.

Patch installed.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/