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

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

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.

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

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, Pennsylvania 19026

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

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

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/