From: "Mark Andrews via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: Re: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Mon, 28 Jul 2008 06:24:18 +0000 > Hello, > > I'm experiencing some problems using IPv6 in bind 9.5.0-P1 tools (dig, host a > nd nslookup). I want them to support IPv6, but its detection in the configure > script fails at test "checking for in6_pktinfo" (others tests about ipv6 wor > k). Here is the config.log part: > > > configure:24917: checking for in6_pktinfo > > configure:24946: gcc -c -g -O2 -I/usr/include/libxml2 conftest.c >&5 > > conftest.c: In function 'main': > > conftest.c:45: error: storage size of 'xyzzy' isn't known > > configure:24952: $? = 1 > > configure: failed program was: > > | /* confdefs.h. */ > > | #define PACKAGE_NAME "" > > [... useless info suppressed ...] > > | #define HAVE_LIBNSL 1 > > | #define WANT_IPV6 1 > > | /* end confdefs.h. */ > > | > > | #include > > | #include > > | #include > > | > > | > > | > > | int > > | main () > > | { > > | struct in6_pktinfo xyzzy; return (0); > > | ; > > | return 0; > > | } > > I digged into that error: the in6_pktinfo is defined in , but s > urrounded by an #ifdef __USE_GNU declaration. However, this glibc internal ma > cro should by set by giving to gcc the -D_GNU_SOURCE flag. > > Another solution is to include the file instead, which also de > fines the in6_pktinfo structure, and does not need the __USE_GNU macro to be > set. But I think it's not a portable way, as it's a linux-related file. > > -- Gilles Bedel Thank you for your report. Please log a bug report with your OS vendor for shipping headers that break the IPv6 API. in6_pktinfo is part of the IPv6 advanced socket API it is not GNU specific. Note: this test used to work. This is a regression on their park. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org ============================================================================= ============================================================================= From: "gillux via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: Re: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Mon, 28 Jul 2008 11:27:47 +0000 On Mon, 28 Jul 2008 06:24:18 +0000 "Mark Andrews via RT" wrote: > > Thank you for your report. Please log a bug report with > your OS vendor for shipping headers that break the IPv6 Sorry I missed that indeed: I use GNU/Linux 2.6.25 on ArchLinux. I use the GNU C Library stable release version 2.8. > in6_pktinfo is part of the IPv6 advanced socket API > it is not GNU specific. I don't think so... is a part of the GNU C library (as the in.h header says). This file is in the glibc cvs. > > Note: this test used to work. This is a regression on their > park. > Indeed, I saw that these #ifdef __USE_GNU were added at 2008/01/16 (revision 1.56), along with the "Cleanup namespace." comment. I believe IPv6 (or at least the in6_pktinfo) must be a GNU extension since glibc 2.8. There are some explanations about that in the glibc faq here : http://www.gnu.org/software/libc/FAQ.html#s-3.1 Just add the -D_GNU_SOURCE to your CFLAGS and everything will be okay. Regards, -- Gilles Bedel ============================================================================= ============================================================================= From: "Mark Andrews via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: Re: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Mon, 28 Jul 2008 13:02:37 +0000 > On Mon, 28 Jul 2008 06:24:18 +0000 > "Mark Andrews via RT" wrote: > > > > > Thank you for your report. Please log a bug report with > > your OS vendor for shipping headers that break the IPv6 > > Sorry I missed that indeed: I use GNU/Linux 2.6.25 on ArchLinux. > I use the GNU C Library stable release version 2.8. > > > in6_pktinfo is part of the IPv6 advanced socket API > > it is not GNU specific. > > I don't think so... is a part of the GNU C library (as the in. > h header says). This file is in the glibc cvs. Firstly existed well before Linux existed. It's part of the BSD Socket API. was in BSD 4.2 and possibly BSD 4.1C and earlier. Please read RFC 2292, Advanced Sockets API for IPv6. This is not, and never has been, Linux / glibc specific. This was obsoleted by RFC 3542. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org ============================================================================= ============================================================================= From: "gillux via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: Re: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Mon, 28 Jul 2008 18:25:08 +0000 On Mon, 28 Jul 2008 13:02:37 +0000 "Mark Andrews via RT" wrote: > Firstly existed well before Linux existed. > It's part of the BSD Socket API. was in > BSD 4.2 and possibly BSD 4.1C and earlier. I don't think "who was the first" really matters. > Please read RFC 2292, Advanced Sockets API for IPv6. This > is not, and never has been, Linux / glibc specific. This > was obsoleted by RFC 3542. Thanks, I red them. These RFCs do not define any standard, they are purely informational : > Status of this Memo > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. However, the GNU C Library follows the POSIX standard, which do not include the specification of in6_pktinfo, and all the things surrounded by #ifdef __USE_GNU. This sounds logic to me: in6_pktinfo is not in the standards, but is only a common community guide. So the GNU guys made it as an extension. Bind9 is working with glibc, so it must set the _GNU_SOURCE flag to use its extensions. -- Gilles Bedel ============================================================================= ============================================================================= From: "Mark Andrews via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: Re: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Mon, 28 Jul 2008 23:21:00 +0000 > On Mon, 28 Jul 2008 13:02:37 +0000 > "Mark Andrews via RT" wrote: > > > Firstly existed well before Linux existed. > > It's part of the BSD Socket API. was in > > BSD 4.2 and possibly BSD 4.1C and earlier. > > I don't think "who was the first" really matters. It does when you are talking about who owns the api. The API does not say #define __USE_GNU. The API already has #defines to let you know which parts of the advanced API are available. > > Please read RFC 2292, Advanced Sockets API for IPv6. This > > is not, and never has been, Linux / glibc specific. This > > was obsoleted by RFC 3542. > > Thanks, I red them. These RFCs do not define any standard, they are purely in > formational : Yes it is Informational. It is however the definition of the API. The structure definition is supposed to be visible just by include . Just as RFC 2133, Basic Socket Interface Extensions for IPv6, and it successors are Informational but define the basic part of the IPv6 socket API. The pair of RFC's were written to work together. They are Informational because the IETF normally doesn't do API's. However if you implement the Advanced IPv6 Socket API then this is how you do it. > > Status of this Memo > > This memo provides information for the Internet community. It does > > not specify an Internet standard of any kind. > > However, the GNU C Library follows the POSIX standard, which do not include t > he specification of in6_pktinfo, and all the things surrounded by #ifdef __US > E_GNU. > > This sounds logic to me: in6_pktinfo is not in the standards, but is only a c > ommon community guide. So the GNU guys made it as an extension. Bind9 is work > ing with glibc, so it must set the _GNU_SOURCE flag to use its extensions. So Sun, HP, IBM, FreeBSD, NetBSD and every other OS which implements the advanced socket API got it wrong. > -- Gilles Bedel -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org ============================================================================= ============================================================================= From: "gillux via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: Re: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Tue, 29 Jul 2008 13:34:25 +0000 On Mon, 28 Jul 2008 23:21:00 +0000 "Mark Andrews via RT" wrote: > > > On Mon, 28 Jul 2008 13:02:37 +0000 > > "Mark Andrews via RT" wrote: > > > > > Firstly existed well before Linux existed. > > > It's part of the BSD Socket API. was in > > > BSD 4.2 and possibly BSD 4.1C and earlier. > > > > I don't think "who was the first" really matters. > > It does when you are talking about who owns the api. > > The API does not say #define __USE_GNU. The API already > has #defines to let you know which parts of the advanced > API are available. > > > > Please read RFC 2292, Advanced Sockets API for IPv6. This > > > is not, and never has been, Linux / glibc specific. This > > > was obsoleted by RFC 3542. > > > > Thanks, I red them. These RFCs do not define any standard, they are purely in > > formational : > > Yes it is Informational. It is however the definition of > the API. The structure definition is supposed to be visible > just by include . > > Just as RFC 2133, Basic Socket Interface Extensions for > IPv6, and it successors are Informational but define the > basic part of the IPv6 socket API. > > The pair of RFC's were written to work together. They are > Informational because the IETF normally doesn't do API's. > However if you implement the Advanced IPv6 Socket API then > this is how you do it. The issue is that both these RFC and POSIX define what's in . But it's not conflictual: the RFCs added some other things. So you have to put a #define before including it to make the preprocessor know what you want (POSIX or RFC) that's all. Why does it really seems to be a pain for you ? Don't you want bind9 to work with the glibc ? > > > Status of this Memo > > > This memo provides information for the Internet community. It does > > > not specify an Internet standard of any kind. > > > > However, the GNU C Library follows the POSIX standard, which do not include t > > he specification of in6_pktinfo, and all the things surrounded by #ifdef __US > > E_GNU. > > > > This sounds logic to me: in6_pktinfo is not in the standards, but is only a c > > ommon community guide. So the GNU guys made it as an extension. Bind9 is work > > ing with glibc, so it must set the _GNU_SOURCE flag to use its extensions. > > So Sun, HP, IBM, FreeBSD, NetBSD and every other OS which > implements the advanced socket API got it wrong. That's not what I said. They only have other ways of doing it (which I don't know, but would be interested to know). What I said is that I explained why the new glibc 2.8 beheaviour is well thought and is not a regression. If you still think is it, I can't do anything more for you: go tell them directly that they've done a mistake. You have made the choice to you work with the glibc, just assume it. Gentoo have already done it by the way : http://bugs.gentoo.org/show_bug.cgi?id=227333 I'm pretty bored about all that: if you don't fix bind9 in your reply, just close this bug. I'll give up and simply ask my distribution to apply that patch. Regards, -- Gilles Bedel ============================================================================= ============================================================================= From: "Francis Dupont via RT" To: <*me*> Reply-To: bind9-bugs@isc.org Subject: [ISC-Bugs #18388] bind-9.5.0-P1 - IPv6 autodetection problem (and fix) in configure script Date: Wed, 30 Jul 2008 08:06:58 +0000 On Tue Jul 29 14:02:38 2008, fdupont wrote: RĂ©ponse personnelle : as an user of Gentoo (but still at the standard glibc version which works well) and having my name in the advanced API RFCs, I'll signal the issue to glibc maintenance. (done, bug 6775)