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

[Chris Wright]

* 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.

thanks,
-chris