[Bug libc/9981] getaddrinfo prefers listening on ipv4-only over ipv4+ipv6

[Bug libc/9981] getaddrinfo prefers listening on ipv4-only over ipv4+ipv6

[allan at archlinux dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Allan McRae <allan at archlinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allan at archlinux dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/9981] getaddrinfo prefers listening on ipv4-only over ipv4+ipv6

[hnsr at xs4all dot nl]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Hans Nieser <hnsr at xs4all dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hnsr at xs4all dot nl

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo prefers listening on ipv4-only over ipv4+ipv6

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |network

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo prefers listening on ipv4-only over ipv4+ipv6

[mmeier at badeio dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Marco Meier <mmeier at badeio dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmeier at badeio dot de

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo prefers listening on ipv4-only over ipv4+ipv6

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |psimerda at redhat dot com
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

--- Comment #4 from Pavel Šimerda <psimerda at redhat dot com> 2012-12-18 14:30:58 UTC ---
Comment from a newer duplicate:

 Pavel Šimerda 2012-12-16 16:08:35 UTC

On Linux, with net.ipv6.bindv6only = 0 (the default), getaddrinfo(NULL) with
AI_PASSIVE returns 0.0.0.0 and :: (in this order). AI_PASSIVE was meant to
return a list of addresses to listen on, but it is impossible to listen on
0.0.0.0 and :: at the same time, if :: implies dualstack mode.

Even the order is wrong, as listening on :: would work for both protocols,
while listening on 0.0.0.0 does not. If the order is fixed, applications could
just spit out a warning but still work correctly.

The only proper fix I can think of, is test for net.ipv6.bindv6only and return
only :: if this is 0, otherwise return both addresses (preferably IPv6 first).

Upstream bug report:

https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/673708

More information:

https://fedoraproject.org/wiki/Networking/NameResolution#Binding_to_the_INADDR_ANY_and.2For_in6addr_any_addresses

Cheers,

Pavel

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|getaddrinfo prefers         |getaddrinfo(NULL) with
                   |listening on ipv4-only over |AI_PASSIVE returns 0.0.0.0
                   |ipv4+ipv6                   |(IPv4-only) and ::
                   |                            |(IPv6+IPv4) in this order

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[psimerda at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=9981

Pavel Šimerda <psimerda at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vapier at gentoo dot org

--- Comment #5 from Pavel Šimerda <psimerda at redhat dot com> 2012-12-22 20:53:03 UTC ---
*** Bug 14211 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[aoliva at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

Alexandre Oliva <aoliva at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at sourceware dot org

--- Comment #7 from Alexandre Oliva <aoliva at sourceware dot org> ---
Created attachment 7624
  --> https://sourceware.org/bugzilla/attachment.cgi?id=7624&action=edit
Don't sort passive localhost addresses, so that IPv6+IPvv4 remains first and
IPv4-only, last

I don't think it ever makes any sense for us to ever try to sort passive
addresses: we always generate them IPv6+IPv4 first and IPv4-only last, with at
most two adresses and possibly only one if we asked for a specific family. 
Since the former is always preferred, it doesn't make sense to try to sort
them.

The only doubt is whether to generate both when the first covers both; I'm not
when dropping the latter is safe, so I'm leaving that unrelated decision out
for now.

Any reason to not go with this patch?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[neleai at seznam dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #8 from Ondrej Bilka <neleai at seznam dot cz> ---
On Sat, May 31, 2014 at 12:52:45AM +0000, aoliva at sourceware dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=9981
> 
> Alexandre Oliva <aoliva at sourceware dot org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |aoliva at sourceware dot org
> 
> --- Comment #7 from Alexandre Oliva <aoliva at sourceware dot org> ---
> Created attachment 7624
>   --> https://sourceware.org/bugzilla/attachment.cgi?id=7624&action=edit
> Don't sort passive localhost addresses, so that IPv6+IPvv4 remains first and
> IPv4-only, last
> 
> I don't think it ever makes any sense for us to ever try to sort passive
> addresses: we always generate them IPv6+IPv4 first and IPv4-only last, with at
> most two adresses and possibly only one if we asked for a specific family. 
> Since the former is always preferred, it doesn't make sense to try to sort
> them.
> 
> The only doubt is whether to generate both when the first covers both; I'm not
> when dropping the latter is safe, so I'm leaving that unrelated decision out
> for now.
> 
> Any reason to not go with this patch?
> 
Possible, you should send this to libc-alpha to get comments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[Ondřej Bílka]

On Sat, May 31, 2014 at 12:52:45AM +0000, aoliva at sourceware dot org wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=9981
> 
> Alexandre Oliva <aoliva at sourceware dot org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |aoliva at sourceware dot org
> 
> --- Comment #7 from Alexandre Oliva <aoliva at sourceware dot org> ---
> Created attachment 7624
>   --> https://sourceware.org/bugzilla/attachment.cgi?id=7624&action=edit
> Don't sort passive localhost addresses, so that IPv6+IPvv4 remains first and
> IPv4-only, last
> 
> I don't think it ever makes any sense for us to ever try to sort passive
> addresses: we always generate them IPv6+IPv4 first and IPv4-only last, with at
> most two adresses and possibly only one if we asked for a specific family. 
> Since the former is always preferred, it doesn't make sense to try to sort
> them.
> 
> The only doubt is whether to generate both when the first covers both; I'm not
> when dropping the latter is safe, so I'm leaving that unrelated decision out
> for now.
> 
> Any reason to not go with this patch?
> 
Possible, you should send this to libc-alpha to get comments.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[bugzilla.sourceware.simon at arlott dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #9 from Simon Arlott <bugzilla.sourceware.simon at arlott dot org> ---
> The only doubt is whether to generate both when the first covers both;
> I'm not when dropping the latter is safe, so I'm leaving that unrelated
> decision out for now.

It's not safe because the global sysctl net.ipv6.bindv6only could be set to 1
at any time, or the application could use IPV6_V6ONLY=1 on the socket
(expecting to receive an IPv4 address too).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[psimerda at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #10 from Pavel Šimerda <psimerda at redhat dot com> ---
(In reply to Simon Arlott from comment #9)
> It's not safe because the global sysctl net.ipv6.bindv6only could be set to
> 1 at any time, or the application could use IPV6_V6ONLY=1 on the socket
> (expecting to receive an IPv4 address too).

Do you see a better way?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-22623-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sat May 31 23:45:56 2014
Return-Path: <glibc-bugs-return-22623-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 13483 invoked by alias); 31 May 2014 23:45:55 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 13401 invoked by uid 48); 31 May 2014 23:45:50 -0000
From: "bugzilla.sourceware.simon at arlott dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order
Date: Sat, 31 May 2014 23:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugzilla.sourceware.simon at arlott dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-9981-131-ga5DLfCAoO@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-9981-131@http.sourceware.org/bugzilla/>
References: <bug-9981-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg00406.txt.bz2
Content-length: 761

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #11 from Simon Arlott <bugzilla.sourceware.simon at arlott dot org> ---
(In reply to Pavel Šimerda from comment #10)
> (In reply to Simon Arlott from comment #9)
> > It's not safe because the global sysctl net.ipv6.bindv6only could be set to
> > 1 at any time, or the application could use IPV6_V6ONLY=1 on the socket
> > (expecting to receive an IPv4 address too).
> 
> Do you see a better way?

There is nothing getaddrinfo() can do about this. It would have been better to
not have the bindv6only sysctl and require an explicit IPV6_V6ONLY=0 on the
socket, but it's too late for that now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-22624-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Jun 01 09:26:32 2014
Return-Path: <glibc-bugs-return-22624-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 7761 invoked by alias); 1 Jun 2014 09:26:32 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 7673 invoked by uid 48); 1 Jun 2014 09:26:24 -0000
From: "psimerda at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order
Date: Sun, 01 Jun 2014 09:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: psimerda at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-9981-131-FCelF7LaP5@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-9981-131@http.sourceware.org/bugzilla/>
References: <bug-9981-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00000.txt.bz2
Content-length: 707

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #12 from Pavel Šimerda <psimerda at redhat dot com> ---
(In reply to Simon Arlott from comment #11)
> There is nothing getaddrinfo() can do about this. It would have been better
> to not have the bindv6only sysctl and require an explicit IPV6_V6ONLY=0 on
> the socket, but it's too late for that now.

Then I would say we should assume bindv6only won't change between the call to
getaddrinfo() and bind(). I know it's not 100% perfect but most systems don't
change the setting at runtime at all. It certainly better than the current
situation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-22625-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Jun 01 09:35:33 2014
Return-Path: <glibc-bugs-return-22625-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 12412 invoked by alias); 1 Jun 2014 09:35:33 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 12345 invoked by uid 48); 1 Jun 2014 09:35:29 -0000
From: "bugzilla.sourceware.simon at arlott dot org" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order
Date: Sun, 01 Jun 2014 09:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: network
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bugzilla.sourceware.simon at arlott dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-9981-131-VAVE74Hyy8@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-9981-131@http.sourceware.org/bugzilla/>
References: <bug-9981-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00001.txt.bz2
Content-length: 1025

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #13 from Simon Arlott <bugzilla.sourceware.simon at arlott dot org> ---
(In reply to Pavel Šimerda from comment #12)
> Then I would say we should assume bindv6only won't change between the call
> to getaddrinfo() and bind(). I know it's not 100% perfect but most systems
> don't change the setting at runtime at all. It certainly better than the
> current situation.

You're making an assumption that the application hasn't been developed to work
around this already. The default is usually bindv6only=0 in the sysctl but I've
written code that sets the IPV6_V6ONLY=1 socket flag specifically so that all
of the getaddrinfo() addresses will bind successfully.

I'd suggest documenting this non-AF-independent behaviour in the man page or
pushing for an AF-independent "I'm using getaddrinfo() so don't try to second
guess what I mean by bind()" socket flag.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-22626-listarch-glibc-bugs=sources.redhat.com@sourceware.org Sun Jun 01 18:50:55 2014
Return-Path: <glibc-bugs-return-22626-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 26043 invoked by alias); 1 Jun 2014 18:50:54 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 25995 invoked by uid 48); 1 Jun 2014 18:50:48 -0000
From: "naroyce at hotmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug build/17007] New: Check Scanf15 bits/syscall.h No such file
Date: Sun, 01 Jun 2014 18:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: build
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: naroyce at hotmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-17007-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00002.txt.bz2
Content-length: 4380

https://sourceware.org/bugzilla/show_bug.cgi?id\x17007

            Bug ID: 17007
           Summary: Check Scanf15 bits/syscall.h No such file
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: naroyce at hotmail dot com
                CC: carlos at redhat dot com

https://lists.debian.org/debian-glibc/2013/11/msg00116.html
It looks like Debian created a patch that I think should be pushed upstream as
I have just now encountered this issue and the patch got me past that issue.

*****
make[2]: Entering directory '/media/tmp/glibc/stdio-common'
gcc scanf15.c -c -std=gnu99 -fgnu89-inline  -O3 -Wall -Winline -Wundef
-Wwrite-strings -fmerge-all-constants -frounding-math -march=armv7-a
-mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -pipe -Wstrict-prototypes
-I../libio -I../stdlib -I../wcsmbs -I../time -I../string -I../wctype -I../misc
   -I/media/ddodroid/usr/include  -I../include
-I/media/tmp/glibcBuild/stdio-common  -I/media/tmp/glibcBuild
-I../sysdeps/unix/sysv/linux/arm  -I../nptl/sysdeps/unix/sysv/linux
-I../nptl/sysdeps/pthread  -I../sysdeps/pthread  -I../sysdeps/unix/sysv/linux
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../nptl/sysdeps/unix/sysv
-I../sysdeps/unix/sysv  -I../sysdeps/unix/arm  -I../nptl/sysdeps/unix
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/arm/armv7/multiarch
-I../sysdeps/arm/armv7  -I../sysdeps/arm/armv6t2  -I../sysdeps/arm/armv6
-I../sysdeps/arm/nptl  -I../sysdeps/arm/include -I../sysdeps/arm
-I../sysdeps/arm/soft-fp  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/flt-32
 -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754  -I../sysdeps/generic
-I../nptl  -I.. -I../libio -I. -nostdinc -isystem
/armv7l-unknown-linux-gnueabihf/lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include
-isystem
/armv7l-unknown-linux-gnueabihf/lib/gcc/armv7l-unknown-linux-gnueabihf/4.10.0/include-fixed
-isystem /media/ddodroid/usr/include  -D_LIBC_REENTRANT -include
../include/libc-symbols.h   -DNOT_IN_libc=1    -D_IO_MTSAFE_IO -o
/media/tmp/glibcBuild/stdio-common/scanf15.o -MD -MP -MF
/media/tmp/glibcBuild/stdio-common/scanf15.o.dt -MT
/media/tmp/glibcBuild/stdio-common/scanf15.o
In file included from ../misc/sys/param.h:28:0,
                 from ../sysdeps/unix/sysv/linux/arm/lowlevellock.h:22,
                 from ../nptl/sysdeps/pthread/bits/stdio-lock.h:23,
                 from ../libio/libio.h:149,
                 from ../libio/stdio.h:74,
                 from scanf15.c:10:
../include/signal.h:44:15: warning: 'struct sigvec' declared inside parameter
list
        struct sigvec *__ovec);
               ^
../include/signal.h:44:15: warning: its scope is only this definition or
declaration, which is probably not what you want
In file included from ../sysdeps/unix/sysdep.h:20:0,
                 from ../sysdeps/unix/arm/sysdep.h:18,
                 from ../sysdeps/unix/sysv/linux/arm/sysdep.h:24,
                 from ../sysdeps/unix/sysv/linux/arm/lowlevellock.h:25,
                 from ../nptl/sysdeps/pthread/bits/stdio-lock.h:23,
                 from ../libio/libio.h:149,
                 from ../libio/stdio.h:74,
                 from scanf15.c:10:
../sysdeps/unix/sysv/linux/sys/syscall.h:31:27: fatal error: bits/syscall.h: No
such file or directory
 # include <bits/syscall.h>
                           ^
compilation terminated.
*****
It happens with both scanf15.c and scanf17.c
Makefile:
*****
# The following is a hack since we must compile scanf1{5,7}.c without any
# GNU extension.  The latter are needed, though, when internal headers
# are used.  So made sure we see the installed headers first.
CFLAGS-scanf15.c = -I../libio -I../stdlib -I../wcsmbs -I../time -I../string \
           -I../wctype
CFLAGS-scanf17.c = -I../libio -I../stdlib -I../wcsmbs -I../time -I../string \
           -I../wctype
*****
"-I\$(common-objpfx)misc" should be appended to both.

$ uname -a
 Linux ddrecovery 3.8.13.23-31165-g849348d #1 SMP PREEMPT Sat May 31 05:57:27
CDT 2014 armv7l GNU/Linux

Using LFS as a guide. But using hard-float for ARM.
I will wipe glibc and glibcBuild and apply the patch and rerun it from scratch
just to make sure.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug network/9981] getaddrinfo(NULL) with AI_PASSIVE returns 0.0.0.0 (IPv4-only) and :: (IPv6+IPv4) in this order

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=9981

--- Comment #14 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, lxoliva/getaddrinfo has been created
        at  d4139de660d1f25ad34ab023b13ec3cad78986d2 (commit)

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d4139de660d1f25ad34ab023b13ec3cad78986d2

commit d4139de660d1f25ad34ab023b13ec3cad78986d2
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sun Jun 1 16:51:57 2014 -0300

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=91bbe1798129768e77cffecf324400fa4d31ad10

commit 91bbe1798129768e77cffecf324400fa4d31ad10
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sun Jun 1 16:51:44 2014 -0300

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=bc3ac8b1779e8b180762841048601b90f469d6e5

commit bc3ac8b1779e8b180762841048601b90f469d6e5
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sun Jun 1 16:48:15 2014 -0300

    for  ChangeLog

        PR network/9981
        * sysdeps/posix/getaddrinfo.c (getaddrinfo): Do not sort
        AI_PASSIVE addresses.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7875573cbe52eabe78f1cab91c8a046d0bd5ed5a

commit 7875573cbe52eabe78f1cab91c8a046d0bd5ed5a
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sat Sep 27 07:13:20 2014 -0300

    drop address family conversions from /etc/hosts parser

    for ChangeLog

        * nss/nss_files/files-hosts.c (LINE_PARSER): Drop all address
        family conversions.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=393207b6a74aeed6227d88174b8b37e4ee095260

commit 393207b6a74aeed6227d88174b8b37e4ee095260
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sat Sep 27 07:13:20 2014 -0300

    drop v4-to-v6 conversions of loopback addresses from /etc/hosts

    for ChangeLog

        * nss/nss_files/files-hosts.c (LINE_PARSER): Drop family
        conversion of loopback addresses from IPv4 to IPv6.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2e8a3341f470d8fa0dce69b8cf83e346a0017ada

commit 2e8a3341f470d8fa0dce69b8cf83e346a0017ada
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sat Sep 27 07:13:18 2014 -0300

    drop v6-to-v4 conversions of loopback addresses from /etc/hosts

    for ChangeLog

        * nss/nss_files/files-hosts.c (LINE_PARSER): Drop family
        conversion of loopback addresses from IPv6 to IPv4.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=901aad32edcbd1cfd57ee904ada6dcc56a53b385

commit 901aad32edcbd1cfd57ee904ada6dcc56a53b385
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Sat Sep 27 07:23:39 2014 -0300

    resolv: skip leading dot in domain to search

    This should only happen if the domain to search is the root,
    represented as . rather than by an empty string.  Skipping it here
    prevents libc_res_nquerydomain from duplicating the trailing dot,
    which would cause the domain name compression to fail.

    for  ChangeLog

        PR 16469
        * resolv/res_query.c (__libc_res_nsearch): Skip leading dot in
        search domain names.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ba878d017e6b65f5d2880ac8262bc68224ee3a53

commit ba878d017e6b65f5d2880ac8262bc68224ee3a53
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Wed Oct 15 03:52:43 2014 -0300

    don't drop trailing dot in res_nquerydomain(..., name, NULL, ...)

    If we drop it here, we will fail to detect a duplicate trailing dot
    later on.  Retaining, OTOH, has no ill effects whatsoever, and it even
    saves us the trouble of copying the domain name minus the trailing
    dot, like we used to do.

    for ChangeLog

        PR 16469
        * resolv/res_query.c (__libc_res_nquerydomain): Retain
            trailing dot.
        * NEWS: Fixes 16469.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ff9a1b7dce77c43235e11cda103698078cf44a45

commit ff9a1b7dce77c43235e11cda103698078cf44a45
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Mon Nov 3 18:51:40 2014 -0200

    Do not continue in nss_db_getservbyname

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=6286965b02069369beeb893833c34f01dc919ffb

commit 6286965b02069369beeb893833c34f01dc919ffb
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Mon Nov 3 18:51:40 2014 -0200

    create all sockets with SOCK_CLOEXEC

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c83b8a87170cda275a5c591fe2a1d3657d2a6711

commit c83b8a87170cda275a5c591fe2a1d3657d2a6711
Author: Alexandre Oliva <aoliva@redhat.com>
Date:   Mon Nov 3 18:51:39 2014 -0200

    introduce internal function to ease poll retry with timeout

-----------------------------------------------------------------------

-- 
You are receiving this mail because:
You are on the CC list for the bug.