Thread: Re: Add support for
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
> 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
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
{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.
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
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
>> 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
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.
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
>> 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
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/
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.
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/
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.