public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: "Hao, Xudong" <xudong.hao@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	Avi Kivity <avi@redhat.com>
Subject: Re: [Qemu-devel] qemu-kvm build issue on RHEL5.1
Date: Thu, 14 Oct 2010 09:33:58 +0900	[thread overview]
Message-ID: <4CB64FF6.5080906@jp.fujitsu.com> (raw)
In-Reply-To: <AANLkTin2nTQ2W=URcpjkrjGtHMzYfdftacwKxb+qdoSx@mail.gmail.com>

(2010/10/14 4:11), Blue Swirl wrote:
> On Wed, Oct 13, 2010 at 8:00 AM, Hidetoshi Seto
> <seto.hidetoshi@jp.fujitsu.com> 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


  reply	other threads:[~2010-10-14  0:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BC00F5384FCFC9499AF06F92E8B78A9E1AC3EFA17E@shsmsx502.ccr.corp.intel.com>
2010-10-13  8:00 ` [Qemu-devel] qemu-kvm build issue on RHEL5.1 Hidetoshi Seto
2010-10-13  8:13   ` Hao, Xudong
2010-10-13 19:11   ` Blue Swirl
2010-10-14  0:33     ` Hidetoshi Seto [this message]
2010-11-04 17:03       ` Chris Wright
2010-11-05  6:32         ` Hidetoshi Seto
2010-11-05  6:32         ` [PATCH] virtio-9p: fix build on !CONFIG_UTIMENSAT v2 Hidetoshi Seto
2010-11-08  6:44           ` [Qemu-devel] " M. Mohan Kumar
2010-11-12 12:33             ` Jes Sorensen
2010-11-14  5:58           ` Chris Wright
2010-11-15  2:10             ` [Qemu-devel] " Hidetoshi Seto
2010-11-15  2:15               ` [PATCH v3] virtio-9p: fix build on !CONFIG_UTIMENSAT Hidetoshi Seto
2010-11-15  3:36                 ` Chris Wright
2010-11-15 16:49                 ` M. Mohan Kumar
2010-11-21 15:22                 ` [Qemu-devel] " Anthony Liguori
2010-11-22  6:28                   ` Jes Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CB64FF6.5080906@jp.fujitsu.com \
    --to=seto.hidetoshi@jp.fujitsu.com \
    --cc=avi@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=xudong.hao@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox