* Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
2019-08-09 12:49 ` Peter Maydell
@ 2019-08-09 13:22 ` Aleksandar Markovic
2019-08-09 13:30 ` Michael Tokarev
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Aleksandar Markovic @ 2019-08-09 13:22 UTC (permalink / raw)
To: Peter Maydell
Cc: Laurent Vivier, Riku Voipio, Markus Armbruster, QEMU Developers
On Fri, Aug 9, 2019 at 2:57 PM Peter Maydell <peter.maydell@linaro.org>
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.
>
> Better fix: patch QEMU to provide its own versions of these constants
> if the system headers don't.
>
>
Another related case, needing internal-to-QEMU ioctl constant definitions:
Linux namespaces and their ioctls:
===========================
http://man7.org/linux/man-pages/man7/namespaces.7.html
http://man7.org/linux/man-pages/man2/ioctl_ns.2.html
Kernel support exist since 4.9 (amended in 4.11), but there is no
header that exposes ioctl definitions - an applications must contain
something like this:
#ifndef NS_GET_USERNS
#define NSIO 0xb7
#define NS_GET_USERNS _IO(NSIO, 0x1)
#define NS_GET_PARENT _IO(NSIO, 0x2)
#endif
QEMU does not support these ioctls (regardless of the presence of
host kernel support) - however, if we had the above definitions in our
code, we could support them (of course, relying on the support in the
host kernel, otherwise we would return "unknown ioctl").
Cordially,
Aleksandar
> 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
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
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:10 ` Peter Maydell
3 siblings, 0 replies; 9+ messages in thread
From: Michael Tokarev @ 2019-08-09 13:30 UTC (permalink / raw)
To: Peter Maydell, Markus Armbruster
Cc: Riku Voipio, QEMU Developers, Laurent Vivier
09.08.2019 15:49, Peter Maydell wrote:
>>> 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)))
[]
> 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.
On debian we have qemu build-conflict with oss4-dev, exactly for this
very reason, - installing oss4-dev breaks qemu build.
Thanks,
/mjt
> Better fix: patch QEMU to provide its own versions of these constants
> if the system headers don't.
[]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
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
2019-08-09 14:10 ` Peter Maydell
3 siblings, 2 replies; 9+ messages in thread
From: Daniel P. Berrangé @ 2019-08-09 13:35 UTC (permalink / raw)
To: Peter Maydell
Cc: Laurent Vivier, Riku Voipio, Markus Armbruster, QEMU Developers
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 ?
> 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 :|
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
2019-08-09 13:35 ` Daniel P. Berrangé
@ 2019-08-09 14:02 ` Peter Maydell
2019-08-09 14:05 ` Aleksandar Markovic
1 sibling, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2019-08-09 14:02 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Laurent Vivier, Riku Voipio, Markus Armbruster, QEMU Developers
On Fri, 9 Aug 2019 at 14:35, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Fri, Aug 09, 2019 at 01:49:07PM +0100, Peter Maydell wrote:
> > Easy fix: uninstall oss4-dev.
>
> Perhaps also make 'configure' exit with an error if it detects the
> broken soundcard.h ?
If you're going to patch QEMU you want this one:
> > Better fix: patch QEMU to provide its own versions of these constants
> > if the system headers don't.
which isn't really any more work.
thanks
-- PMM
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
2019-08-09 13:35 ` Daniel P. Berrangé
2019-08-09 14:02 ` Peter Maydell
@ 2019-08-09 14:05 ` Aleksandar Markovic
1 sibling, 0 replies; 9+ messages in thread
From: Aleksandar Markovic @ 2019-08-09 14:05 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: QEMU Developers, Peter Maydell, Riku Voipio, Laurent Vivier,
Markus Armbruster
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 :|
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Does i386-linux-user build on an i686 host?
2019-08-09 12:49 ` Peter Maydell
` (2 preceding siblings ...)
2019-08-09 13:35 ` Daniel P. Berrangé
@ 2019-08-09 14:10 ` Peter Maydell
3 siblings, 0 replies; 9+ messages in thread
From: Peter Maydell @ 2019-08-09 14:10 UTC (permalink / raw)
To: Markus Armbruster
Cc: Riku Voipio, Michael Tokarev, QEMU Developers, Laurent Vivier
On Fri, 9 Aug 2019 at 13:49, Peter Maydell <peter.maydell@linaro.org> wrote:
> 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...
I missed out this other option:
Make The World A Better Place fix:
Report bug and/or provide patch to the oss4-dev headers to
augment them to provide all the ioctl numbers and other
constants that the kernel's version does, so they really
are interoperable with the header they're diverting.
thanks
-- PMM
^ permalink raw reply [flat|nested] 9+ messages in thread