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: David Miller <davem at davemloft dot net>
- To: vapier at gentoo dot org
- Cc: 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,carlos at systemhalted dot org
- Date: Wed, 16 Jan 2013 13:57:44 -0500 (EST)
- Subject: Re: Redefinition of struct in6_addr in <netinet/in.h> and<linux/in6.h>
- References: <50F6B761.email@example.com><firstname.lastname@example.org><email@example.com>
From: Mike Frysinger <firstname.lastname@example.org>
Date: Wed, 16 Jan 2013 12:04:56 -0500
> certainly true, but the current expectation is that you don't mix your ABIs.
> if you're programming with the C library API, then use the C library headers.
> if you're banging directly on the kernel, then use the kernel headers. not
> saying it's a perfect solution, but it works for the vast majority of use
This isn't how real life works.
GLIBC itself brings in some of the kernel headers, as do various library
headers for libraries other than glibc.
So you can get these conflicting headers included indirectly, and it is
of no fault of any of the various parties involved.
We have to make them work when included at the same time somehow, and
this is totally unavoidable.