Re: [Qemu-devel] Does i386-linux-user build on an i686 host?

[Peter Maydell <peter.maydell@linaro.org>]

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.

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