Bug 1002735
Summary: | libvirt should work around broken <linux/if_bridge.h> | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Eric Blake <eblake> | ||||
Component: | libvirt | Assignee: | Eric Blake <eblake> | ||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.5 | CC: | acathrow, ajia, chhu, cwei, dwrobel, dyuan, eblake, gansalmon, harald, itamar, jdenemar, jforbes, joel, jonathan, kernel-maint, lsu, madhu.chinakonda, roysjosh | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | libvirt-0.10.2-24.el6 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | 895141 | Environment: | |||||
Last Closed: | 2013-11-21 09:09:37 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 895141 | ||||||
Bug Blocks: | 994265 | ||||||
Attachments: |
|
Description
Eric Blake
2013-08-29 20:15:01 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> 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...) 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 ? (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. (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. 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 I don't think it's worth backporting to 6.5 at this time. 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 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. If you still see the error, can you attach config.log from the failed build? (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. Created attachment 821417 [details]
configuration's log
(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 (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 (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 ? 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. (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. (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. (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. 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 |