Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1

[Hidetoshi Seto]

(2010/11/05 2:03), Chris Wright wrote:
> * Hidetoshi Seto (address@hidden) wrote:
>> (2010/10/14 4:11), Blue Swirl wrote:
>>> On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto
>>> <address@hidden> wrote:
>>>> (Add CC to address@hidden)
>>>>
>>>> (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.

According to the commit 74bc02b2d2272dc88fb98d43e631eb154717f517, the
title "Do not reset atime" can tell us that the original motivation to
use utimensat() is not for the resolution.

Anyway, I agree to have something like qemu_utimensat().
I made a patch for the first step, and will post it next to this reply. 


Thanks,
H.Seto