Pete Forman wrote:
> The basic problem is that <netinet/tcp.h> is a BSD header.  The
> correct header for TCP internals such as TCP_NODELAY on a UNIX system
> is <xti.h>.  By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1) or later.
> The 2 files which conditionally include <netinet/tcp.h> need also to
> conditionally include <xti.h>.

This patch is causing compilation warnings on HPUX 10.20:

gcc -c  -I../../../src/include  -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -o pqcomm.o pqcomm.c
In file included from pqcomm.c:76:
/usr/include/netinet/tcp.h:71: warning: `TCP_NODELAY' redefined
/usr/include/sys/xti.h:469: warning: this is the location of the previous definition
/usr/include/netinet/tcp.h:72: warning: `TCP_MAXSEG' redefined
/usr/include/sys/xti.h:470: warning: this is the location of the previous definition

I have never heard of <xti.h> before and am rather dubious that it
should be considered more standard than <tcp.h>.  However, if we are
going to include it then it evidently must be *mutually exclusive*
with including <tcp.h>.  The $64 question is, which one ought to be
included when both are available?  I'd tend to go for <tcp.h> on the
grounds of "don't fix what wasn't broken".

Actually, given your description of the problem, I'm half inclined to
revert the whole patch and instead make configure's test for
availability of <netinet/tcp.h> first include <netinet/in.h>, so that
that configure test will succeed on IRIX etc.  Do you know any platforms
where <tcp.h> doesn't exist at all?

			regards, tom lane

Thu, 19 Oct 2000 23:09:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Add support for <xti.h>
> Pete Forman wrote:
> > The basic problem is that <netinet/tcp.h> is a BSD header.  The
> > correct header for TCP internals such as TCP_NODELAY on a UNIX system
> > is <xti.h>.  By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1) or later.
> > The 2 files which conditionally include <netinet/tcp.h> need also to
> > conditionally include <xti.h>.
> 
> This patch is causing compilation warnings on HPUX 10.20:
> 
> gcc -c  -I../../../src/include  -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -o pqcomm.o pqcomm.c
> In file included from pqcomm.c:76:
> /usr/include/netinet/tcp.h:71: warning: `TCP_NODELAY' redefined
> /usr/include/sys/xti.h:469: warning: this is the location of the previous definition
> /usr/include/netinet/tcp.h:72: warning: `TCP_MAXSEG' redefined
> /usr/include/sys/xti.h:470: warning: this is the location of the previous definition
> 
> I have never heard of <xti.h> before and am rather dubious that it

Yes, I never heard of xti.h either.

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

Thu, 19 Oct 2000 23:33:19 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: Add support for <xti.h>
On my UnixWare Box, both xti.h and netinet/... are present.

(Arguably the ONE TRUE UNIX, decendant from the ATT sources, and all
that rot, and current highest SysVrX release, at SysV R5). 

LER

* Bruce Momjian <pgman@candle.pha.pa.us> [001019 22:34]:
> > Pete Forman wrote:
> > > The basic problem is that <netinet/tcp.h> is a BSD header.  The
> > > correct header for TCP internals such as TCP_NODELAY on a UNIX system
> > > is <xti.h>.  By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1) or later.
> > > The 2 files which conditionally include <netinet/tcp.h> need also to
> > > conditionally include <xti.h>.
> > 
> > This patch is causing compilation warnings on HPUX 10.20:
> > 
> > gcc -c  -I../../../src/include  -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -o pqcomm.o pqcomm.c
> > In file included from pqcomm.c:76:
> > /usr/include/netinet/tcp.h:71: warning: `TCP_NODELAY' redefined
> > /usr/include/sys/xti.h:469: warning: this is the location of the previous definition
> > /usr/include/netinet/tcp.h:72: warning: `TCP_MAXSEG' redefined
> > /usr/include/sys/xti.h:470: warning: this is the location of the previous definition
> > 
> > I have never heard of <xti.h> before and am rather dubious that it
> 
> Yes, I never heard of xti.h either.
> 
> -- 
>   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
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Thu, 19 Oct 2000 23:00:55 -0500
Larry Rosenman <ler@lerctr.org>
Re: Re: Add support for <xti.h>
Tom Lane writes:
 > Pete Forman wrote:
 > > The basic problem is that <netinet/tcp.h> is a BSD header.  The
 > > correct header for TCP internals such as TCP_NODELAY on a UNIX
 > > system is <xti.h>.  By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1)
 > > or later.  The 2 files which conditionally include
 > > <netinet/tcp.h> need also to conditionally include <xti.h>.

I've done bit more research.  <xti.h> was the correct place to find
TCP_NODELAY in UNIX98/SUSv2.  However in the Austin Group draft of the
next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and
<netinet/tcp.h>  officially included.

 > I have never heard of <xti.h> before and am rather dubious that it
 > should be considered more standard than <tcp.h>.  However, if we
 > are going to include it then it evidently must be *mutually
 > exclusive* with including <tcp.h>.  The $64 question is, which one
 > ought to be included when both are available?  I'd tend to go for
 > <tcp.h> on the grounds of "don't fix what wasn't broken".
 > 
 > Actually, given your description of the problem, I'm half inclined
 > to revert the whole patch and instead make configure's test for
 > availability of <netinet/tcp.h> first include <netinet/in.h>, so
 > that that configure test will succeed on IRIX etc.  Do you know any
 > platforms where <tcp.h> doesn't exist at all?

I agree with this.  Back out the patch and update configure.in.  I
might have done that myself but I do not have enough experience with
autoconf.

The only platform I know of without <netinet/tcp.h> is Cygwin B20.1.
There is a workaround in place for that.  The current Cygwin 1.1 does
have the header.
-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
Western Geophysical           -./\.-  by myself and does not represent
pete.forman@westgeo.com         -./\.-  the opinion of Baker Hughes or
http://www.crosswinds.net/~petef  -./\.-  its divisions.

Fri, 20 Oct 2000 14:04:16 +0100 (BST)
Pete Forman <gsez020@mandy.bedford.waii.com>
Re: Add support for <xti.h>
{retry of message sent Fri, 20 Oct 2000 14:04:16 +0100 (BST)]

Tom Lane writes:
 > Pete Forman wrote:
 > > The basic problem is that <netinet/tcp.h> is a BSD header.  The
 > > correct header for TCP internals such as TCP_NODELAY on a UNIX
 > > system is <xti.h>.  By UNIX I mean UNIX95 (aka XPG4v2 or SUSv1)
 > > or later.  The 2 files which conditionally include
 > > <netinet/tcp.h> need also to conditionally include <xti.h>.

I've done bit more research.  <xti.h> was the correct place to find
TCP_NODELAY in UNIX98/SUSv2.  However in the Austin Group draft of the
next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and
<netinet/tcp.h>  officially included.

 > I have never heard of <xti.h> before and am rather dubious that it
 > should be considered more standard than <tcp.h>.  However, if we
 > are going to include it then it evidently must be *mutually
 > exclusive* with including <tcp.h>.  The $64 question is, which one
 > ought to be included when both are available?  I'd tend to go for
 > <tcp.h> on the grounds of "don't fix what wasn't broken".
 > 
 > Actually, given your description of the problem, I'm half inclined
 > to revert the whole patch and instead make configure's test for
 > availability of <netinet/tcp.h> first include <netinet/in.h>, so
 > that that configure test will succeed on IRIX etc.  Do you know any
 > platforms where <tcp.h> doesn't exist at all?

I agree with this.  Back out the patch and update configure.in.  I
might have done that myself but I do not have enough experience with
autoconf.

The only platform I know of without <netinet/tcp.h> is Cygwin B20.1.
There is a workaround in place for that.  The current Cygwin 1.1 does
have the header.

-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
Western Geophysical           -./\.-  by myself and does not represent
pete.forman@westgeo.com         -./\.-  the opinion of Baker Hughes or
http://www.crosswinds.net/~petef  -./\.-  its divisions.

Mon, 23 Oct 2000 08:50:37 +0100 (BST)
Pete Forman <gsez020@kryten.bedford.waii.com>
Re: Add support for <xti.h>
Pete Forman <gsez020@kryten.bedford.waii.com> writes:
> I've done bit more research.  <xti.h> was the correct place to find
> TCP_NODELAY in UNIX98/SUSv2.  However in the Austin Group draft of the
> next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and
> <netinet/tcp.h>  officially included.

OK, thanks for following up on that.

>> to revert the whole patch and instead make configure's test for
>> availability of <netinet/tcp.h> first include <netinet/in.h>, so
>> that that configure test will succeed on IRIX etc.

> I agree with this.  Back out the patch and update configure.in.

Will do.

			regards, tom lane

Mon, 23 Oct 2000 09:35:36 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Add support for <xti.h> 
xti.h portion of patch has been backed out.


> Pete Forman <gsez020@kryten.bedford.waii.com> writes:
> > I've done bit more research.  <xti.h> was the correct place to find
> > TCP_NODELAY in UNIX98/SUSv2.  However in the Austin Group draft of the
> > next version of POSIX and UNIX0x/SUSv3, XTI has been dropped and
> > <netinet/tcp.h>  officially included.
> 
> OK, thanks for following up on that.
> 
> >> to revert the whole patch and instead make configure's test for
> >> availability of <netinet/tcp.h> first include <netinet/in.h>, so
> >> that that configure test will succeed on IRIX etc.
> 
> > I agree with this.  Back out the patch and update configure.in.
> 
> Will do.
> 
> 			regards, tom lane
> 


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

Mon, 23 Oct 2000 10:45:28 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Add support for <xti.h>
>> Actually, given your description of the problem, I'm half inclined
>> to revert the whole patch and instead make configure's test for
>> availability of <netinet/tcp.h> first include <netinet/in.h>, so
>> that that configure test will succeed on IRIX etc.

Pete,
  After looking at this I'm confused again.  The configure test
consists of seeing whether cpp will process

	#include <netinet/tcp.h>

without complaint.  I can well believe that the full C compilation
process will generate errors if <netinet/tcp.h> is included without
also including <netinet/in.h>, but it's a little harder to believe
that cpp alone will complain.  Could you double-check this?

It would be useful to look at the config.log file generated by the
configure run that's reporting tcp.h isn't found.  It should contain
the error messages generated by failed tests.

			regards, tom lane

Mon, 23 Oct 2000 12:19:41 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Add support for <xti.h> 
Tom Lane writes:
 > >> Actually, given your description of the problem, I'm half
 > >> inclined to revert the whole patch and instead make configure's
 > >> test for availability of <netinet/tcp.h> first include
 > >> <netinet/in.h>, so that that configure test will succeed on IRIX
 > >> etc.
 > 
 > Pete,
 >   After looking at this I'm confused again.  The configure test
 > consists of seeing whether cpp will process
 > 
 > 	#include <netinet/tcp.h>
 > 
 > without complaint.  I can well believe that the full C compilation
 > process will generate errors if <netinet/tcp.h> is included without
 > also including <netinet/in.h>, but it's a little harder to believe
 > that cpp alone will complain.  Could you double-check this?
 > 
 > It would be useful to look at the config.log file generated by the
 > configure run that's reporting tcp.h isn't found.  It should
 > contain the error messages generated by failed tests.

On IRIX 6.5.5m I get the following error.  The header <standards.h> is
included by (nearly!) all of the standard headers.  It is the IRIX
equivalent of config.h if you will.

In order to preprocess this test on IRIX a system header such as
<stdio.h> must precede <netinet/tcp.h>.  The logical choice of header
to use is <netinet/in.h> as tcp.h is supplying values for levels
defined in in.h.

This is an IRIX bug but I think that we need to work around it.


configure:4349: checking for netinet/tcp.h
configure:4359: cc -E   conftest.c >/dev/null 2>conftest.out
cc-1035 cc: WARNING File = /usr/include/sys/endian.h, Line = 32
  #error directive:  "<standards.h> must be included before <sys/endian.h>."

  #error "<standards.h> must be included before <sys/endian.h>."
   ^
configure: failed program was:
#line 4354 "configure"
#include "confdefs.h"
#include <netinet/tcp.h>



-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
Western Geophysical           -./\.-  by myself and does not represent
pete.forman@westgeo.com         -./\.-  the opinion of Baker Hughes or
http://www.crosswinds.net/~petef  -./\.-  its divisions.

Tue, 24 Oct 2000 10:40:34 +0100 (BST)
Pete Forman <gsez020@kryten.bedford.waii.com>
Re: Re: Add support for <xti.h> 
Pete Forman <gsez020@kryten.bedford.waii.com> writes:
> On IRIX 6.5.5m I get the following error.  The header <standards.h> is
> included by (nearly!) all of the standard headers.  It is the IRIX
> equivalent of config.h if you will.

> configure:4349: checking for netinet/tcp.h
> configure:4359: cc -E   conftest.c >/dev/null 2>conftest.out
> cc-1035 cc: WARNING File = /usr/include/sys/endian.h, Line = 32
>   #error directive:  "<standards.h> must be included before <sys/endian.h>."

>   #error "<standards.h> must be included before <sys/endian.h>."
>    ^
> configure: failed program was:
> #line 4354 "configure"
> #include "confdefs.h"
> #include <netinet/tcp.h>

How bizarre.  One would think it'd make more sense to just include the
desired file, instead of going belly-up like that.

> In order to preprocess this test on IRIX a system header such as
> <stdio.h> must precede <netinet/tcp.h>.  The logical choice of header
> to use is <netinet/in.h> as tcp.h is supplying values for levels
> defined in in.h.

> This is an IRIX bug but I think that we need to work around it.

Roger, will do.

			regards, tom lane

Tue, 24 Oct 2000 10:37:15 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: Add support for <xti.h> 
>> This is an IRIX bug but I think that we need to work around it.

> Roger, will do.

I have changed configure in the CVS repository to test for netinet/tcp.h
per your recommendation.  At your convenience, please verify that it
really does do the right thing on IRIX.

			regards, tom lane

Tue, 24 Oct 2000 11:07:33 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: Add support for <xti.h> 
Tom Lane writes:

>   After looking at this I'm confused again.  The configure test
> consists of seeing whether cpp will process
> 
> 	#include <netinet/tcp.h>
> 
> without complaint.  I can well believe that the full C compilation
> process will generate errors if <netinet/tcp.h> is included without
> also including <netinet/in.h>, but it's a little harder to believe
> that cpp alone will complain.  Could you double-check this?

I'm not quite sure whether it explains it, but note that preprocessor
checks also "fail" when warnings are generated.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Tue, 24 Oct 2000 18:09:14 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Re: Add support for <xti.h> 
Tom Lane writes:
 > >> This is an IRIX bug but I think that we need to work around it.
 > 
 > > Roger, will do.
 > 
 > I have changed configure in the CVS repository to test for
 > netinet/tcp.h per your recommendation.  At your convenience, please
 > verify that it really does do the right thing on IRIX.

Yes, that works.


There is a separate problem running the configure script on AIX.  It
hangs while testing for flex.  The two processes that I killed to
allow configure to continue were

    /usr/ccs/bin/lex --version
    /usr/bin/lex --version

The problem is that lex is waiting for input from stdin.  This patch
should fix it.   I've only tested modification of the configure file
directly.

*** config/programs.m4.orig     Mon Aug 28 12:53:13 2000
--- config/programs.m4  Wed Oct 25 10:20:31 2000
***************
*** 22,28 ****
      for pgac_prog in flex lex; do
        pgac_candidate="$pgac_dir/$pgac_prog"
        if test -f "$pgac_candidate" \
!         && $pgac_candidate --version >/dev/null 2>&1
        then
          echo '%%'  > conftest.l
          if $pgac_candidate -t conftest.l 2>/dev/null | grep FLEX_SCANNER >/dev/null 2>&1; then
--- 22,28 ----
      for pgac_prog in flex lex; do
        pgac_candidate="$pgac_dir/$pgac_prog"
        if test -f "$pgac_candidate" \
!         && $pgac_candidate --version </dev/null >/dev/null 2>&1
        then
          echo '%%'  > conftest.l
          if $pgac_candidate -t conftest.l 2>/dev/null | grep FLEX_SCANNER >/dev/null 2>&1; then



-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
Western Geophysical           -./\.-  by myself and does not represent
pete.forman@westgeo.com         -./\.-  the opinion of Baker Hughes or
http://www.crosswinds.net/~petef  -./\.-  its divisions.

Wed, 25 Oct 2000 10:37:31 +0100 (BST)
Pete Forman <gsez020@kryten.bedford.waii.com>
Re: Re: Add support for <xti.h> 
Pete Forman writes:

> There is a separate problem running the configure script on AIX.  It
> hangs while testing for flex.  The two processes that I killed to
> allow configure to continue were
> 
>     /usr/ccs/bin/lex --version
>     /usr/bin/lex --version
> 
> The problem is that lex is waiting for input from stdin.  This patch
> should fix it.   I've only tested modification of the configure file
> directly.

Done.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Thu, 26 Oct 2000 18:34:10 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Re: Add support for <xti.h> 