[Bug network/15850] New: Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[Bug network/15850] New: Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[xiyou.wangcong at gmail dot com]

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

            Bug ID: 15850
           Summary: Glibc headers have conflicts with kernel headers on
                    the definition of struct in6_addr
           Product: glibc
           Version: 2.18
            Status: NEW
          Severity: normal
          Priority: P2
         Component: network
          Assignee: unassigned at sourceware dot org
          Reporter: xiyou.wangcong at gmail dot com

/usr/include/netinet/in.h:35:5: error: expected identifier before numeric
constant
/usr/include/netinet/in.h:197:8: error: redefinition of 'struct in6_addr'
In file included from /usr/include/linux/if_bridge.h:17:0,
                   from src/tethering.c:38:
/usr/include/linux/in6.h:30:8: note: originally defined here


Test cases:


#include <netinet/in.h>
#include <linux/in6.h>
int main (void) {
  return 0;
}


#include <linux/in6.h>
#include <netinet/in.h>
int main (void) {
  return 0;
}

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
We run into this kind of problem with musl quite a bit too, and I don't think
there's a proper solution except documenting that the kernel headers should not
be included in userspace except when they provide something that has no
corresponding libc interface. Any solution in glibc would be either:

A. Specific to certain versions of the kernel headers, and would still leave
you stuck with problems when using older kernel headers, OR

B. Would cause glibc's headers to be non-conforming (mostly in the sense of
namespace-pollution) unless you got really lucky with the version of the kernel
headers you use.

I don't see either of these as reasonable trade-offs. Back in the 90s, glibc
made the (correct) decision to avoid depending on the kernel headers (although
it still does in a few places) to provide the standard userspace headers.
Application developers just need to learn to stop senselessly including things
from <linux/*.h>.

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[carlos at redhat dot com]

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

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #1)
> We run into this kind of problem with musl quite a bit too, and I don't
> think there's a proper solution except documenting that the kernel headers
> should not be included in userspace except when they provide something that
> has no corresponding libc interface. Any solution in glibc would be either:
> 
> A. Specific to certain versions of the kernel headers, and would still leave
> you stuck with problems when using older kernel headers, OR
> 
> B. Would cause glibc's headers to be non-conforming (mostly in the sense of
> namespace-pollution) unless you got really lucky with the version of the
> kernel headers you use.
> 
> I don't see either of these as reasonable trade-offs. Back in the 90s, glibc
> made the (correct) decision to avoid depending on the kernel headers
> (although it still does in a few places) to provide the standard userspace
> headers. Application developers just need to learn to stop senselessly
> including things from <linux/*.h>.

C. Coordinate.

We can fix this problem but it requires coordination.

I started some work on this and Cong is taking this to completion:

http://sourceware.org/ml/libc-alpha/2013-08/msg00208.html

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[bugdal at aerifal dot cx]

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

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
I don't see "C. Coordinate" as an alternative to the problems A and B above.
The coordination only works with new post-coordination kernel header versions
(problem A). Assuming glibc is still producing its own definitions rather than
including the kernel headers (and just turning off its own definitions if the
kernel version was already included), problem B does not occur in the case of
strictly conforming applications which are not including the linux/*.h headers.
However, there's still the possibility of unexpected inconsistency for
applications which do use linux/*.h.

I'm not sure what the intended usage case you're trying to support is. If your
intent is that the headers roughly match, then it seems like applications
should not be including the linux ones, and I'm not sure why it's more
desirable to "support" this case and get it 90-99% "right" instead of just
documenting that it's wrong (and possibly even using #error to correct this bad
practice).

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[carlos at redhat dot com]

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

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #3)
> I don't see "C. Coordinate" as an alternative to the problems A and B above.
> The coordination only works with new post-coordination kernel header
> versions (problem A). Assuming glibc is still producing its own definitions
> rather than including the kernel headers (and just turning off its own
> definitions if the kernel version was already included), problem B does not
> occur in the case of strictly conforming applications which are not
> including the linux/*.h headers. However, there's still the possibility of
> unexpected inconsistency for applications which do use linux/*.h.

Sorry Rich, I have had little sleep and I was being a bit tongue-in-cheek here. 

Regardless of how much coordination we have if you have an old system you will
still have "A." (dependence on new glibc and new kernel headers).

I think that "B." will depend largely on the exact headers you are trying to
fix and this is why we're trying to resolve these one at a time for each
header.

However, it is true that in this particular case the glibc headers will choose
specifically not to define certain structures if it is known that kernel header
provides a conforming definition.

> I'm not sure what the intended usage case you're trying to support is. If
> your intent is that the headers roughly match, then it seems like
> applications should not be including the linux ones, and I'm not sure why
> it's more desirable to "support" this case and get it 90-99% "right" instead
> of just documenting that it's wrong (and possibly even using #error to
> correct this bad practice).

It's not wrong, and we should support it.

What do we loose by coordinating the two sets of headers?

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[bugdal at aerifal dot cx]

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

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> ---
In terms of "what do we lose?" I think the answers are:

1. People power that could be better spent elsewhere. Of course it's your right
to spend your time on what matters most to you, but glibc has a lot more
functional bugs than people to fix them all. Also, perhaps a bulk of the work
is initial support, but I suspect there will be some maintenance cost too,
which others may inherit having to deal with in the future.

2. Consistency of behavior. I would rather have the duplication of libc and
kernel headers result consistently in #error than have it work 99% of the time,
but sometimes fail when someone installs new kernel headers that weren't
properly tested.

The order-of-inclusion dependency is very bothering too. Presumably the reason
someone might include the kernel header is to get bleeding-edge things not yet
in the libc header. But if the kernel header's definitions are suppressed if
the libc version was included first, this means applications need to be very
careful to control the inclusion order, and it might get reversed if another
third-party header includes the libc header first.

I would much rather see:

#include <netinet/in.h>
#include <linux/extra_stuff_that_does_not_belong_in_in.h>

than having overlapping headers with subtle differences.

Aside from all of the above, my feeling is that history has shown that trying
to synchronize this kind of header issue, where a definition might have
different sources, is a nightmare. Think of things like the use of bool in
curses. Historically, the Linux headers have not been userspace-friendly, and
have been a source of header-incompatibility breakage, and I don't see the
value in doing anything that would encourage people to go back to using them
more...

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[neleai at seznam dot cz]

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

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |neleai at seznam dot cz
         Resolution|---                         |FIXED

--- Comment #6 from Ondrej Bilka <neleai at seznam dot cz> ---
Fixed by 6c82a2f8.

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 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, master has been updated
       via  e732c5f04958e535fa309b0fae50d67063a1a203 (commit)
      from  a494421f5268df333c589d71104a39bb6a9cff19 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit e732c5f04958e535fa309b0fae50d67063a1a203
Author: Carlos O'Donell <carlos@redhat.com>
Date:   Sun Jan 12 12:17:33 2014 -0500

    Add BZ #15850 to ChangeLog.

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

Summary of changes:
 ChangeLog |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

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

[Bug network/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[fweimer at redhat dot com]

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

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/15850] Glibc headers have conflicts with kernel headers on the definition of struct in6_addr

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 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, master has been updated
       via  cb43bb0d68f001fc3d6e054d712ab8794b5fd1de (commit)
      from  9be1052b6f7583fad365643169cfc6732c96aee3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

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

commit cb43bb0d68f001fc3d6e054d712ab8794b5fd1de
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Tue Jan 6 16:13:19 2015 -0800

    in.h: Coordinate in6_pktinfo and ip6_mtuinfo for kernel and glibc [BZ
#15850]

    Similarly to what we did for in6_addr, we need a macro
    to guard in6_pktinfo and ip6_mtuinfo too.

    Cc: Carlos O'Donell <carlos@redhat.com>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>

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

Summary of changes:
 ChangeLog                         |    8 ++++++++
 inet/netinet/in.h                 |    3 ++-
 sysdeps/unix/sysv/linux/bits/in.h |    8 ++++----
 3 files changed, 14 insertions(+), 5 deletions(-)

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