RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1002735 - libvirt should work around broken <linux/if_bridge.h>
Summary: libvirt should work around broken <linux/if_bridge.h>
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Eric Blake
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 895141
Blocks: 994265
TreeView+ depends on / blocked
 
Reported: 2013-08-29 20:15 UTC by Eric Blake
Modified: 2013-11-21 09:09 UTC (History)
18 users (show)

Fixed In Version: libvirt-0.10.2-24.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 895141
Environment:
Last Closed: 2013-11-21 09:09:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
configuration's log (1.23 MB, text/plain)
2013-11-08 02:44 UTC, Luwen Su 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1581 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2013-11-21 01:11:35 UTC

Description Eric Blake 2013-08-29 20:15:01 UTC 
Cloning to libvirt so I can backport an upstream libvirt workaround patch into the 6.5 build, so that libvirt need not depend on the whims of the kernel folks messing with this in 6.5.

+++ This bug was initially created as a clone of Bug #895141 +++

Description of problem:
POSIX requires that standard headers should be self-contained.  While headers under the linux/ namespace are (obviously) not standardized, it is nicer if they abide by the same rules.  It is a pain to have to write applications that pre-include other headers before being able to use a kernel header.

Version-Release number of selected component (if applicable):
kernel-headers-3.8.0-0.rc3.git0.1.fc19.i686

How reproducible:
100%

Steps to Reproduce:
1. cat foo.c
2. gcc -c -Wall foo.c
3. gcc -c -Wall foo.c -DWORKAROUND
  
Actual results:
1.
#ifdef WORKAROUND
#include <netinet/ip6.h>
#endif
#include <linux/if_bridge.h>

2.
In file included from foo.c:4:0:
/usr/include/linux/if_bridge.h:172:20: error: field ‘ip6’ has incomplete type

3. clean compilation

Expected results:
both 2 and 3 should give clean compilation

Additional info:
see also https://www.redhat.com/archives/libvir-list/2013-January/msg00930.html for a real-life project impacted by this header bug

--- Additional comment from Josh Boyer on 2013-01-14 11:48:04 MST ---

Can you report this upstream?  3.8 is still in the -rc phase, so there's a chance it can get fixed by the upstream developers before 3.8 releases.

--- Additional comment from Eric Blake on 2013-01-14 14:11:28 MST ---

(In reply to comment #1)
> Can you report this upstream?

Having never reported an upstream kernel bug before, how best do I go about doing that?

--- Additional comment from Eric Blake on 2013-01-16 11:56:46 MST ---

Looks like others are aware of this issue, given that this thread cc'd netdev.org: https://www.redhat.com/archives/libvir-list/2013-January/msg00981.html

--- Additional comment from Fedora End Of Life on 2013-04-03 09:43:29 MDT ---

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

--- Additional comment from Justin M. Forbes on 2013-04-05 12:51:32 MDT ---

Is this still an issue with the 3.9 kernels in F19?

--- Additional comment from Eric Blake on 2013-04-05 13:41:00 MDT ---

Not just in F19, but also rawhide:

$ gcc -c -Wall foo.c
In file included from foo.c:4:0:
/usr/include/linux/if_bridge.h:183:20: error: field ‘ip6’ has incomplete type
    struct in6_addr ip6;
                    ^

$ rpm -q kernel-headers
kernel-headers-3.9.0-0.rc5.git1.1.fc20.i686

--- Additional comment from Josh Boyer on 2013-04-08 07:12:20 MDT ---



--- Additional comment from Harald Hoyer on 2013-04-09 10:23:19 MDT ---

when will this be fixed?

--- Additional comment from Justin M. Forbes on 2013-04-10 08:22:41 MDT ---

Upstream discussion on it is a mess due to conflicting definitions. No clue as to when it will actually be fixed.

--- Additional comment from Damian Wrobel on 2013-08-07 07:09:55 MDT ---

Just faced the same problem on F19 using kernel-headers-3.10.4-300.fc19.x86_64.

For the record the commit which broke it: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee07c6e7a6f8a25c18f0a6b18152fbd7499245f6
Comment 1 Eric Blake 2013-08-29 20:17:31 UTC 
I plan on backporting this (and possibly its pre-reqs) so that we are immune to the kernel churn while building libvirt, instead of being at their mercy.

commit 70024dc9192038575ab5217ac35080b038e5b13e
Author: Eric Blake <eblake>
Date:   Wed Aug 7 10:34:08 2013 -0600

    build: more workarounds for if_bridge.h
    
    This is a second attempt at fixing the problem first attempted
    in commit 2df8d99; basically undoing the fact that it was
    reverted in commit 43cee32f, plus fixing two more issues: the
    code in configure.ac has to EXACTLY match virnetdevbridge.c
    with regards to declaring in6 types before using if_bridge.h,
    and the fact that RHEL 5 has even more conflicts:
    
    In file included from util/virnetdevbridge.c:49:
    /usr/include/linux/in6.h:47: error: conflicting types for 'in6addr_any'
    /usr/include/netinet/in.h:206: error: previous declaration of 'in6addr_any' was here
    /usr/include/linux/in6.h:49: error: conflicting types for 'in6addr_loopback'
    /usr/include/netinet/in.h:207: error: previous declaration of 'in6addr_loopback' was here
    
    The rest of this commit message borrows from the original try
    of 2df8d99:
    
    A fresh checkout on a RHEL 6 machine with these packages:
    kernel-headers-2.6.32-405.el6.x86_64
    glibc-2.12-1.128.el6.x86_64
    failed to configure with this message:
    checking for linux/if_bridge.h... no
    configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support
    
    Digging in config.log, we see that the problem is identical to
    what we fixed earlier in commit d12c2811:
    
    configure:98831: checking for linux/if_bridge.h
    configure:98853: gcc -std=gnu99 -c -g -O2  conftest.c >&5
    In file included from /usr/include/linux/if_bridge.h:17,
                     from conftest.c:559:
    /usr/include/linux/in6.h:31: error: redefinition of 'struct in6_addr'
    /usr/include/linux/in6.h:48: error: redefinition of 'struct sockaddr_in6'
    /usr/include/linux/in6.h:56: error: redefinition of 'struct ipv6_mreq'
    configure:98860: $? = 1
    
    I had not hit it earlier because I was using incremental builds,
    where config.cache had shielded me from the kernel-headers breakage.
    
    * configure.ac (if_bridge.h): Avoid conflicting type definitions.
    * src/util/virnetdevbridge.c (includes): Also sanitize for RHEL 5.
    
    Signed-off-by: Eric Blake <eblake>
Comment 2 Eric Blake 2013-08-29 21:06:59 UTC 
In POST with message id <1377810308-23267-1-git-send-email-eblake> (I'd link to the URL on the rhvirt-patches archives, but it has been stuck for 48 hours now...)
Comment 7 chhu 2013-09-09 10:12:01 UTC 
Tried to reproduce the bug with packages: 
kernel-headers-2.6.32-405.el6.x86_64, 
glibc-2.12-1.128.el6.x86_64.
libvirt-0.10.2-20.el6.src.rpm

Steps:
1. # more foo.c
#ifdef WORKAROUND
#include <netinet/ip6.h>
#endif
#include <linux/if_bridge.h>

2. # gcc -c -Wall foo.c
3. # gcc -c -Wall foo.c -DWORKAROUND
In file included from /usr/include/linux/if_bridge.h:17,
                 from foo.c:4:
/usr/include/linux/in6.h:31: error: redefinition of ‘struct in6_addr’
/usr/include/linux/in6.h:48: error: redefinition of ‘struct sockaddr_in6’
/usr/include/linux/in6.h:56: error: redefinition of ‘struct ipv6_mreq’

4. then try to reproduce similar error while rebuilding libvirt.
# rpm -ivh libvirt-0.10.2-20.el6.src.rpm
# cd /root/rpmbuild/SOURCES
# gunzip -c libvirt-0.10.2.tar.gz | tar xvf -
# cd libvirt-0.10.2

run 'configure' and 'make' successfully without error
# ./configure
# make

Could you please give me some advice or steps to reproduce/verify this bug ?
Comment 8 Eric Blake 2013-09-09 12:12:37 UTC 
(In reply to chhu from comment #7)
> Tried to reproduce the bug with packages: 
> kernel-headers-2.6.32-405.el6.x86_64, 
> glibc-2.12-1.128.el6.x86_64.
> libvirt-0.10.2-20.el6.src.rpm
> 
> Steps:
> 1. # more foo.c
> #ifdef WORKAROUND
> #include <netinet/ip6.h>
> #endif
> #include <linux/if_bridge.h>
> 
> 2. # gcc -c -Wall foo.c
> 3. # gcc -c -Wall foo.c -DWORKAROUND
> In file included from /usr/include/linux/if_bridge.h:17,
>                  from foo.c:4:
> /usr/include/linux/in6.h:31: error: redefinition of ‘struct in6_addr’
> /usr/include/linux/in6.h:48: error: redefinition of ‘struct sockaddr_in6’
> /usr/include/linux/in6.h:56: error: redefinition of ‘struct ipv6_mreq’

So you've proved that the kernel-headers 2.6.32-405 is partially broken: if a user includes <netinet/ip6.h> first, then the <linux/if_bridge.h> header fails to compile.  Unfortunately, this setup is REQUIRED by some non-RHEL setups, so libvirt compiles as if WORKAROUND were defined.

> 
> 4. then try to reproduce similar error while rebuilding libvirt.
> # rpm -ivh libvirt-0.10.2-20.el6.src.rpm
> # cd /root/rpmbuild/SOURCES
> # gunzip -c libvirt-0.10.2.tar.gz | tar xvf -
> # cd libvirt-0.10.2
> 
> run 'configure' and 'make' successfully without error
> # ./configure
> # make

The mere fact that you can compile libvirt-0.10.2-24 proves that libvirt is working around whatever the kernel throws at us.  You only compiled 0.10.2-20, which proves that it works around some kernels, but not all.  But if 0.10.2-24 compiles, then this bug is verified.
Comment 9 chhu 2013-09-10 02:16:47 UTC 
(In reply to Eric Blake from comment #8)
> (In reply to chhu from comment #7)
> > Tried to reproduce the bug with packages: 
> > kernel-headers-2.6.32-405.el6.x86_64, 
> > glibc-2.12-1.128.el6.x86_64.
> > libvirt-0.10.2-20.el6.src.rpm
> > 
> > Steps:
> > 1. # more foo.c
> > #ifdef WORKAROUND
> > #include <netinet/ip6.h>
> > #endif
> > #include <linux/if_bridge.h>
> > 
> > 2. # gcc -c -Wall foo.c
> > 3. # gcc -c -Wall foo.c -DWORKAROUND
> > In file included from /usr/include/linux/if_bridge.h:17,
> >                  from foo.c:4:
> > /usr/include/linux/in6.h:31: error: redefinition of ‘struct in6_addr’
> > /usr/include/linux/in6.h:48: error: redefinition of ‘struct sockaddr_in6’
> > /usr/include/linux/in6.h:56: error: redefinition of ‘struct ipv6_mreq’
> 
> So you've proved that the kernel-headers 2.6.32-405 is partially broken: if
> a user includes <netinet/ip6.h> first, then the <linux/if_bridge.h> header
> fails to compile.  Unfortunately, this setup is REQUIRED by some non-RHEL
> setups, so libvirt compiles as if WORKAROUND were defined.
> 
> > 
> > 4. then try to reproduce similar error while rebuilding libvirt.
> > # rpm -ivh libvirt-0.10.2-20.el6.src.rpm
> > # cd /root/rpmbuild/SOURCES
> > # gunzip -c libvirt-0.10.2.tar.gz | tar xvf -
> > # cd libvirt-0.10.2
> > 
> > run 'configure' and 'make' successfully without error
> > # ./configure
> > # make
> 
> The mere fact that you can compile libvirt-0.10.2-24 proves that libvirt is
> working around whatever the kernel throws at us.  You only compiled
> 0.10.2-20, which proves that it works around some kernels, but not all.  But
> if 0.10.2-24 compiles, then this bug is verified.

Thanks Eric Blake!

Verified with the packages:
libvirt-0.10.2-24.el6
glibc-2.12-1.128.el6.x86_64
kernel-headers-2.6.32-405.el6.x86_64

Steps:
# rpm -ivh libvirt-0.10.2-24.el6.src.rpm
# cd /root/rpmbuild/SOURCES
# gunzip -c libvirt-0.10.2.tar.gz | tar xvf -
# cd libvirt-0.10.2
# ./configure
# make
# make install
# libvirtd
on another terminal run:
# virsh list --all
 Id    Name                           State
----------------------------------------------------

Test results:
Compiled libvirt-0.10.2-24 successfully, so changed the status to verified.
Comment 10 Eric Blake 2013-09-13 16:37:31 UTC 
Bummer - the rawhide kernel has FINALLY fixed Bug #895141 in a DIFFERENT manner than the current RHEL headers, which has once again caused a FTBFS for libvirt.  I'm inclined to reopen this bug until we pick up the latest fix:

https://www.redhat.com/archives/libvir-list/2013-September/msg00801.html
Comment 11 Jiri Denemark 2013-09-16 11:53:44 UTC 
I don't think it's worth backporting to 6.5 at this time.
Comment 12 Luwen Su 2013-11-06 06:17:56 UTC 
Hi Eric , 

Per comment 10 and 11 , should we reopen this bug and move to 6.6 ?

my test result basing on 
libvirt-0.10.2-29.el6.src.rpm 
kernel-headers-2.6.32-430.el6.x86_64

checking linux/if_bridge.h usability... no
checking linux/if_bridge.h presence... yes
configure: WARNING: linux/if_bridge.h: present but cannot be compiled
configure: WARNING: linux/if_bridge.h:     check for missing prerequisite headers?
configure: WARNING: linux/if_bridge.h: see the Autoconf documentation
configure: WARNING: linux/if_bridge.h:     section "Present But Cannot Be Compiled"
configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------- ##
configure: WARNING:     ## Report this to libvir-list ##
configure: WARNING:     ## ------------------------------------- ##
checking for linux/if_bridge.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support
Comment 13 Jiri Denemark 2013-11-07 14:03:13 UTC 
Strange, I just tried building with kernel-headers-2.6.32-427.el6.x86_64 and kernel-headers-2.6.32-430.el6.x86_64 and libvirt-0.10.2-29.el6 compiled successfully against both versions. So I guess something else must be wrong on your host.
Comment 14 Jiri Denemark 2013-11-07 14:41:08 UTC 
If you still see the error, can you attach config.log from the failed build?
Comment 15 Eric Blake 2013-11-07 15:54:06 UTC 
(In reply to time.su from comment #12)
> Hi Eric , 
> 
> Per comment 10 and 11 , should we reopen this bug and move to 6.6 ?

No; right now we're building just fine for 6.5, and there's enough time before 6.6 for the kernel/glibc folks to actually get it right without regressing, so it's not worth disturbing the status quo. We'll play it by ear, and open a new bug if upstream kernel headers cause any future build breakage (at which point we should know what patches to backport for libvirt builds).

(In reply to Jiri Denemark from comment #14)
> If you still see the error, can you attach config.log from the failed build?

An error against a current 6.5 setup would be the only reason to reopen this bug.
Comment 16 Luwen Su 2013-11-08 02:44:46 UTC 
Created attachment 821417 [details]
configuration's log
Comment 17 Luwen Su 2013-11-08 02:50:25 UTC 
(In reply to Jiri Denemark from comment #14)
> If you still see the error, can you attach config.log from the failed build?

Still reproduced after re-install my test machine

#rpm -ivh libvirt-0.10.2-29.el6.src.rpm
#rpmbuild -bp libvirt.spec
#pwd
/root/rpmbuild/BUILD/libvirt-0.10.2

#./configure 
.................
configure: WARNING: linux/if_bridge.h: present but cannot be compiled
configure: WARNING: linux/if_bridge.h:     check for missing prerequisite headers?
configure: WARNING: linux/if_bridge.h: see the Autoconf documentation
configure: WARNING: linux/if_bridge.h:     section "Present But Cannot Be Compiled"
configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result
configure: WARNING:     ## ------------------------------------- ##
configure: WARNING:     ## Report this to libvir-list ##
configure: WARNING:     ## ------------------------------------- ##
checking for linux/if_bridge.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support


#uname -a
Linux localhost.localdomain 2.6.32-430.el6.x86_64 #1 SMP Tue Nov 5 15:06:01 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

# rpm -q kernel-headers
kernel-headers-2.6.32-430.el6.x86_64
Comment 18 Jiri Denemark 2013-11-08 09:59:17 UTC 
(In reply to time.su from comment #17)
> (In reply to Jiri Denemark from comment #14)
> > If you still see the error, can you attach config.log from the failed build?
> 
> Still reproduced after re-install my test machine
> 
> #rpm -ivh libvirt-0.10.2-29.el6.src.rpm
> #rpmbuild -bp libvirt.spec
> #pwd
> /root/rpmbuild/BUILD/libvirt-0.10.2
> 
> #./configure 

I see, that's not the right way of building libvirt as it skips autoreconf. You need to let libvirt.spec to build it. You can rebuild libvirt using

rpmbuild -bc libvirt.spec

or just

rpmbuild --rebuild libvirt-0.10.2-29.el6.src.rpm
Comment 19 Luwen Su 2013-11-11 07:39:26 UTC 
(In reply to Jiri Denemark from comment #18)
> (In reply to time.su from comment #17)
> > (In reply to Jiri Denemark from comment #14)
> > > If you still see the error, can you attach config.log from the failed build?
> > 
> > Still reproduced after re-install my test machine
> > 
> > #rpm -ivh libvirt-0.10.2-29.el6.src.rpm
> > #rpmbuild -bp libvirt.spec
> > #pwd
> > /root/rpmbuild/BUILD/libvirt-0.10.2
> > 
> > #./configure 
> 
> I see, that's not the right way of building libvirt as it skips autoreconf.
> You need to let libvirt.spec to build it. You can rebuild libvirt using
> 
> rpmbuild -bc libvirt.spec
> 
> or just
> 
> rpmbuild --rebuild libvirt-0.10.2-29.el6.src.rpm


Yeah , i know , both rebuild and -bb are fine .  I mean if user just run ./configure by himself and get stuck , it worth file a bug ? Or the behaviour don't  supported  by official ?
Comment 20 Jiri Denemark 2013-11-11 08:39:44 UTC 
There's no bug here. Some of the patches in the source RPM touch configure.ac and thus ./configure script is out-of-date until autoreconf is run. Running ./configure without refreshing it from configure.ac won't work.
Comment 21 Alex Jia 2013-11-11 15:15:04 UTC 
(In reply to Jiri Denemark from comment #20)
> There's no bug here. Some of the patches in the source RPM touch
> configure.ac and thus ./configure script is out-of-date until autoreconf is
> run. Running ./configure without refreshing it from configure.ac won't work.

Yes, the configure script is out-of-date, but users used to run ./configure rather than ./autoreconf then they will hit previous error, I'm not sure if we need to document this for users.
Comment 22 Eric Blake 2013-11-11 15:23:56 UTC 
(In reply to Alex Jia from comment #21)
> (In reply to Jiri Denemark from comment #20)
> > There's no bug here. Some of the patches in the source RPM touch
> > configure.ac and thus ./configure script is out-of-date until autoreconf is
> > run. Running ./configure without refreshing it from configure.ac won't work.
> 
> Yes, the configure script is out-of-date, but users used to run ./configure
> rather than ./autoreconf then they will hit previous error, I'm not sure if
> we need to document this for users.

Huh?  There is no './autoreconf'; only 'autoreconf' or './autogen.sh'.  If you are building an rpm, you should use the commands documented in the spec file (directly running ./configure on sources extracted from an rpm is not supported when the rpm itself already documents that it will run autoreconf).  If you are building from an upstream tarball instead of an rpm, then you will hit a FTBFS if you try to build the stock 0.10.2 tarball; but that is NOT the tarball we are building for RHEL, and that FTBFS will also go away if you instead use upstream 0.10.2.8, so it is irrelevant to this BZ.  I see no need for additional documentation - you're trying to make an issue out of something that can only be attributed to abusing the correct build procedures.
Comment 23 Alex Jia 2013-11-11 15:41:14 UTC 
(In reply to Eric Blake from comment #22)
> this BZ.  I see no need for additional documentation - you're trying to make
> an issue out of something that can only be attributed to abusing the correct
> build procedures.

Eric, thanks for details. BTW, sometimes, QE need to apply patches(from devs) to verify some bug then they hack SPECS/libvirt.spec and add corresponding patch name, and then they only run 'rpmbuild -bp SPECS/libvirt.spec" to apply all of patches, as usual, they also hit compiling error, but as you said, it's not a correct build procedures.
Comment 25 errata-xmlrpc 2013-11-21 09:09:37 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1581.html
Note You need to log in before you can comment on or make changes to this bug.