[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
From: |
Hidetoshi Seto |
Subject: |
Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1 |
Date: |
Thu, 14 Oct 2010 09:33:58 +0900 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 |
(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.
... 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