Thread: Re: Add support for

Re: Add support for

From
Tom Lane
Date:
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


Re: Re: Add support for

From
Bruce Momjian
Date:
> 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,
Pennsylvania19026
 


Re: Re: Add support for

From
Larry Rosenman
Date:
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

Re: Add support for

From
Pete Forman
Date:
{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
headerfor 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
questionis, which one> ought to be included when both are available?  I'd tend to go for> <tcp.h> on the grounds of
"don'tfix what wasn't broken".> > Actually, given your description of the problem, I'm half inclined> to revert the
wholepatch and instead make configure's test for> availability of <netinet/tcp.h> first include <netinet/in.h>, so>
thatthat 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.


Re: Add support for

From
Tom Lane
Date:
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


Re: Add support for

From
Bruce Momjian
Date:
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,
Pennsylvania19026
 


Re: Add support for

From
Tom Lane
Date:
>> 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


Re: Re: Add support for

From
Pete Forman
Date:
Tom Lane writes:> >> Actually, given your description of the problem, I'm half> >> inclined to revert the whole patch
andinstead make configure's> >> test for availability of <netinet/tcp.h> first include> >> <netinet/in.h>, so that that
configuretest will succeed on IRIX> >> etc.> > Pete,>   After looking at this I'm confused again.  The configure test>
consistsof seeing whether cpp will process> >     #include <netinet/tcp.h>> > without complaint.  I can well believe
thatthe 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
wouldbe 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.


Re: Re: Add support for

From
Tom Lane
Date:
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


Re: Re: Add support for

From
Tom Lane
Date:
>> 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


Re: Re: Add support for

From
Peter Eisentraut
Date:
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/



Re: Re: Add support for

From
Pete Forman
Date:
Tom Lane writes:> >> This is an IRIX bug but I think that we need to work around it.> > > Roger, will do.> > I have
changedconfigure 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.


Re: Re: Add support for

From
Peter Eisentraut
Date:
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/



Re: Add support for

From
Pete Forman
Date:
Tom Lane writes:> Pete Forman wrote:> > The basic problem is that <netinet/tcp.h> is a BSD header.  The> > correct
headerfor 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
questionis, which one> ought to be included when both are available?  I'd tend to go for> <tcp.h> on the grounds of
"don'tfix what wasn't broken".> > Actually, given your description of the problem, I'm half inclined> to revert the
wholepatch and instead make configure's test for> availability of <netinet/tcp.h> first include <netinet/in.h>, so>
thatthat 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.