[HACKERS] 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 [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
Re: [HACKERS] 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 [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] 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 21 then echo '%%' conftest.l if $pgac_candidate -t conftest.l 2/dev/null | grep FLEX_SCANNER /dev/null 21; 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 21 then echo '%%' conftest.l if $pgac_candidate -t conftest.l 2/dev/null | grep FLEX_SCANNER /dev/null 21; then -- Pete Forman -./\.- Disclaimer: This post is originated Western Geophysical -./\.- by myself and does not represent [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
Re: [HACKERS] 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
Re: [HACKERS] Re: Add support for xti.h
Pete Forman [EMAIL PROTECTED] 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 2conftest.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: [HACKERS] 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 2conftest.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 [EMAIL PROTECTED] -./\.- the opinion of Baker Hughes or http://www.crosswinds.net/~petef -./\.- its divisions.
[HACKERS] 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
[HACKERS] Re: Add support for xti.h
Pete Forman [EMAIL PROTECTED] 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
[HACKERS] 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 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: [HACKERS] 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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] 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 [EMAIL PROTECTED] [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 [EMAIL PROTECTED] | (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: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 PGP signature
