Re: [libvirt] Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>

On 01/18/2013 05:44 AM, Pedro Alves wrote: > On 01/18/2013 04:22 AM, Carlos O'Donell wrote: >> On Thu, Jan 17, 2013 at 11:20 PM, Mike Frysinger <vapier(a)gentoo.org&gt; wrote: >>> On Wednesday 16 January 2013 22:15:38 David Miller wrote: >>>> From: Carlos O'Donell <carlos(a)systemhalted.org&gt; >>>> 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. >>> -mike >> >> 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: > > #ifndef __IPV6_BITS_DEFINED > #define __IPV6_BITS_DEFINED > ... > define in6_addr, sockaddr_in6, ipv6_mreq, whatnot > #endif