This is the mail archive of the
mailing list for the glibc project.
Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
- From: Pedro Alves <palves at redhat dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: Mike Frysinger <vapier at gentoo dot org>, David Miller <davem at davemloft dot net>, libc-alpha at sourceware dot org, bhutchings at solarflare dot com, yoshfuji at linux-ipv6 dot org, amwang at redhat dot com, tmb at mageia dot org, eblake at redhat dot com, netdev at vger dot kernel dot org, linux-kernel at vger dot kernel dot org, libvirt-list at redhat dot com, tgraf at suug dot ch, schwab at suse dot de
- Date: Fri, 18 Jan 2013 10:44:53 +0000
- Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
- References: <email@example.com> <50F75EA7.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <CAE2sS1jMhnRcoo1oe7wQ+SP=40u9mkps6vXua8TQQ4Tbf2qKOQ@mail.gmail.com>
On 01/18/2013 04:22 AM, Carlos O'Donell wrote:
> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger <email@example.com> wrote:
>> On Wednesday 16 January 2013 22:15:38 David Miller wrote:
>>> From: Carlos O'Donell <firstname.lastname@example.org>
>>> Date: Wed, 16 Jan 2013 21:15:03 -0500
>>>> +/* If a glibc-based userspace has already included in.h, then we will
>>>> not + * define in6_addr (nor the defines), sockaddr_in6, or ipv6_mreq.
>>>> The + * ABI used by the kernel and by glibc match exactly. Neither the
>>>> kernel + * nor glibc should break this ABI without coordination.
>>>> + */
>>>> +#ifndef _NETINET_IN_H
>>> I think we should shoot for a non-glibc-centric solution.
>>> I can't imagine that other libc's won't have the same exact problem
>>> with their netinet/in.h conflicting with the kernel's, redefining
>>> structures like in6_addr, that we'd want to provide a protection
>>> scheme for here as well.
>> yes, the kernel's use of __GLIBC__ in exported headers has already caused
>> problems in the past. fortunately, it's been reduced down to just one case
>> now (stat.h). let's not balloon it back up.
> I also see coda.h has grown a __GLIBC__ usage.
> In the next revision of the patch I created a single libc-compat.h header
> which encompasses the logic for any libc that wants to coordinate with
> the kernel headers.
> It's simple enough to move all of the __GLIBC__ uses into libc-compat.h,
> then you control userspace libc coordination from one file.
How about just deciding on a single macro/symbol both the
kernel and libc (any libc that needs this) define? Something
like both the kernel and userland doing:
define in6_addr, sockaddr_in6, ipv6_mreq, whatnot
So whichever the application includes first, wins.
Too naive? I didn't see this option being discarded, so
not sure it was considered.