From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wright Subject: Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1 Date: Thu, 4 Nov 2010 10:03:03 -0700 Message-ID: <20101104170303.GE15211@sequoia.sous-sol.org> References: <4CB56715.7080605@jp.fujitsu.com> <4CB64FF6.5080906@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Blue Swirl , "Hao, Xudong" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity To: Hidetoshi Seto Return-path: Received: from sous-sol.org ([216.99.217.87]:34941 "EHLO sequoia.sous-sol.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751984Ab0KDRDk (ORCPT ); Thu, 4 Nov 2010 13:03:40 -0400 Content-Disposition: inline In-Reply-To: <4CB64FF6.5080906@jp.fujitsu.com> Sender: kvm-owner@vger.kernel.org List-ID: * Hidetoshi Seto (seto.hidetoshi@jp.fujitsu.com) wrote: > (2010/10/14 4:11), Blue Swirl wrote: > > On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto > > wrote: > >> (Add CC to kvm@vger) > >> > >> (2010/10/12 10:52), Hao, Xudong wrote: > >>> Hi, > >>> Currently qemu-kvm build fail on RHEL5 with gcc 4.1.2, build can pass on Fedora11 with gcc 4.4.1, can anybody look on RHEL5 system? > >>> > >>> Gcc: 4.1.2 > >>> system: RHEL5.1 > >>> qemu-kvm: 85566812a4f8cae721fea0224e05a7e75c08c5dd > >>> > >>> ... > >>> LINK qemu-img > >>> LINK qemu-io > >>> CC libhw64/virtio-9p-local.o > >>> cc1: warnings being treated as errors > >>> /home/source/qemu-kvm/hw/virtio-9p-local.c: In function 'local_utimensat': > >>> /home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: implicit declaration of function 'utimensat' > >>> /home/source/qemu-kvm/hw/virtio-9p-local.c:479: warning: nested extern declaration of 'utimensat' > >>> make[1]: *** [virtio-9p-local.o] Error 1 > >>> make: *** [subdir-libhw64] Error 2 > >>> > >>> > >>> Best Regards, > >>> Xudong Hao > >> > >> It seems that this issue is caused by the old glibc. > >> Though I don't know well about virtio-9p and suppose there > >> should be better fix, I confirmed that following change > >> removed the warnings. > > > > But then the system call will be made blindly without checking if the > > kernel supports utimensat(). At the minimum, there should be a sane > > response to ENOSYS error. > > Yes. But I'm not sure how this virtio-9p should behave if there is > no utimensat. I think it will be better to fix this warning first > to allow fellows using RHEL5 to restart contribute on qemu-kvm, > and change this issue to virtio-9p specific problem to allow > specialists of virtio-9p to have discussion for fix without > bothering other developers. One way to workaround this is to simply not install libattr-devel (effecitvely disabling virtio-9p). But I agree with Blue Swirl, need a better fallback plan. A qemu local implementation of something like qemu_utimensat() that simply uses glibc/kernel interface when available and falls back to using utimes() makes sense to me. Then the worst case is loss of resolution from ns to us. thanks, -chris