From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hidetoshi Seto Subject: Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1 Date: Thu, 14 Oct 2010 09:33:58 +0900 Message-ID: <4CB64FF6.5080906@jp.fujitsu.com> References: <4CB56715.7080605@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Hao, Xudong" , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Avi Kivity To: Blue Swirl Return-path: Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:34474 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751784Ab0JNAe3 (ORCPT ); Wed, 13 Oct 2010 20:34:29 -0400 Received: from m1.gw.fujitsu.co.jp ([10.0.50.71]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id o9E0YR25016333 for (envelope-from seto.hidetoshi@jp.fujitsu.com); Thu, 14 Oct 2010 09:34:27 +0900 Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2875345DE58 for ; Thu, 14 Oct 2010 09:34:27 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id E15E745DE53 for ; Thu, 14 Oct 2010 09:34:26 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id C58011DB804B for ; Thu, 14 Oct 2010 09:34:26 +0900 (JST) Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7F8FC1DB8045 for ; Thu, 14 Oct 2010 09:34:26 +0900 (JST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: (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. ... Or is it better to put abort() here instead of syscall? > > What happens if the system headers do not define SYS_utimensat? I suppose build will fail, say, we might need incremental patch named "fix build on RHEL4" or so. But I have no idea, whether there could be a workaround if there is no utimensat, whether we could provide something like wrapper named compat_utimensat or qemu_utimensat, and/or whether it makes sense if virtio-9p have dependency with presence of utimensat. Thanks, H.Seto