From: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
Peter Maydell <peter.maydell@linaro.org>,
Riku Voipio <riku.voipio@iki.fi>,
Laurent Vivier <Laurent@vivier.eu>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
Date: Fri, 9 Aug 2019 16:05:36 +0200 [thread overview]
Message-ID: <CAL1e-=g6LPH318p2ocUtrt+0P32nnyg8q1+Ko-KYHmrxuEVsxg@mail.gmail.com> (raw)
In-Reply-To: <20190809133514.GF13660@redhat.com>
On Fri, Aug 9, 2019 at 3:35 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
> On Fri, Aug 09, 2019 at 01:49:07PM +0100, Peter Maydell wrote:
> > On Fri, 9 Aug 2019 at 13:22, Peter Maydell <peter.maydell@linaro.org>
> wrote:
> > >
> > > On Thu, 8 Aug 2019 at 16:37, Markus Armbruster <armbru@redhat.com>
> wrote:
> > > >
> > > > Fails for me, but perhaps I'm doing it wrong:
> > >
> > >
> > > > NOTE: cross-compilers enabled: 'cc'
> > > > $ make
> > > > CC i386-linux-user/linux-user/syscall.o
> > > > /home/armbru/qemu/linux-user/ioctls.h:306:9: error:
> ‘SNDCTL_DSP_MAPINBUF’ undeclared here (not in a function)
> > > > IOCTL(SNDCTL_DSP_MAPINBUF, IOC_R,
> MK_PTR(MK_STRUCT(STRUCT_buffmem_desc)))
> > > > ^
> > > > /home/armbru/qemu/linux-user/syscall.c:5023:23: note: in definition
> of macro ‘IOCTL’
> > > > { TARGET_ ## cmd, cmd, #cmd, access, 0, { __VA_ARGS__ } },
> > > > ^
> > > > /home/armbru/qemu/linux-user/ioctls.h:307:9: error:
> ‘SNDCTL_DSP_MAPOUTBUF’ undeclared here (not in a function)
> > > > IOCTL(SNDCTL_DSP_MAPOUTBUF, IOC_R,
> MK_PTR(MK_STRUCT(STRUCT_buffmem_desc)))
> > > > ^
> > > > /home/armbru/qemu/linux-user/syscall.c:5023:23: note: in definition
> of macro ‘IOCTL’
> > > > { TARGET_ ## cmd, cmd, #cmd, access, 0, { __VA_ARGS__ } },
> > > > ^
> > > > /home/armbru/qemu/linux-user/ioctls.h:362:9: error:
> ‘SOUND_MIXER_ACCESS’ undeclared here (not in a function)
> > > > IOCTL(SOUND_MIXER_ACCESS, 0, TYPE_PTRVOID)
> > > > ^
> > > > /home/armbru/qemu/linux-user/syscall.c:5023:23: note: in definition
> of macro ‘IOCTL’
> > > > { TARGET_ ## cmd, cmd, #cmd, access, 0, { __VA_ARGS__ } },
> > > > ^
> > >
> > > We expect these to be provided by the system's "linux/soundcard.h".
> > > For my Debian system that's provided by the linux-libc-dev package,
> > > but I imagine you have that installed or you wouldn't have got
> > > this far in the configure/compile process...
> >
> > Further investigation shows that this is because the system has
> > the 'oss4-dev' package installed, which diverts
> /usr/include/linux/soundcard.h
> > and installs its own version which doesn't provide all the symbols
> > that the kernel one does.
> >
> > Easy fix: uninstall oss4-dev.
>
> Perhaps also make 'configure' exit with an error if it detects the
> broken soundcard.h ?
>
>
Daniel, it looks to me that this is too drastic. Only applicable ioctl
support
could be removed for such case, QEMU is otherwise fine.
Yours,
Aleksandar
> > Better fix: patch QEMU to provide its own versions of these constants
> > if the system headers don't.
> >
> > Utopian fix: I've wondered occasionally whether for cases like this
> > where the constant is known to be the same for the host and the guest
> > we should have some sort of approach which lets us use the QEMU
> > copies of the linux kernel headers rather than having to rely on
> > the host system, which might have an older version that restricts
> > us unnecessarily on what we could support...
> >
> > Issue previously reported in 2016:
> > https://lists.gnu.org/archive/html/qemu-devel/2016-12/msg01421.html
> >
> > thanks
> > -- PMM
> >
>
> Regards,
> Daniel
> --
> |: https://berrange.com -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org -o-
> https://www.instagram.com/dberrange :|
>
>
next prev parent reply other threads:[~2019-08-09 14:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 15:37 [Qemu-devel] Does i386-linux-user build on an i686 host? Markus Armbruster
2019-08-09 12:22 ` Peter Maydell
2019-08-09 12:49 ` Peter Maydell
2019-08-09 13:22 ` Aleksandar Markovic
2019-08-09 13:30 ` Michael Tokarev
2019-08-09 13:35 ` Daniel P. Berrangé
2019-08-09 14:02 ` Peter Maydell
2019-08-09 14:05 ` Aleksandar Markovic [this message]
2019-08-09 14:10 ` Peter Maydell
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='CAL1e-=g6LPH318p2ocUtrt+0P32nnyg8q1+Ko-KYHmrxuEVsxg@mail.gmail.com' \
--to=aleksandar.m.mail@gmail.com \
--cc=Laurent@vivier.eu \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/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;
as well as URLs for NNTP newsgroup(s).