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

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

[Markus Armbruster]

Fails for me, but perhaps I'm doing it wrong:

$ uname -a
Linux gcc45 3.16.0-7-686-pae #1 SMP Debian 3.16.59-1 (2018-10-03) i686 GNU/Linux
$ ../configure --target-list=i386-linux-user
Install prefix    /usr/local
BIOS directory    /usr/local/share/qemu
firmware path     /usr/local/share/qemu-firmware
binary directory  /usr/local/bin
library directory /usr/local/lib
module directory  /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory  /usr/local/etc
local state directory   /usr/local/var
Manual directory  /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
Source path       /home/armbru/qemu
GIT binary        git
GIT submodules    ui/keycodemapdb tests/fp/berkeley-testfloat-3 tests/fp/berkeley-softfloat-3 dtc capstone slirp
C compiler        cc
Host C compiler   cc
C++ compiler      c++
Objective-C compiler clang
ARFLAGS           rv
CFLAGS            -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g 
QEMU_CFLAGS       -I/usr/include/pixman-1  -I$(SRC_PATH)/dtc/libfdt -Werror  -pthread -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include  -fPIE -DPIE -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99  -Wendif-labels -Wno-missing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-strong -Wno-missing-braces -I/usr/include/p11-kit-1    -I/usr/include/libpng12  -I$(SRC_PATH)/capstone/include
LDFLAGS           -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m32 -g 
QEMU_LDFLAGS      -L$(BUILD_DIR)/dtc/libfdt 
make              make
install           install
python            python3 -B (3.4.2)
slirp support     git 
smbd              /usr/sbin/smbd
module support    no
host CPU          i386
host big endian   no
target list       i386-linux-user
gprof enabled     no
sparse enabled    no
strip binaries    yes
profiler          no
static build      no
SDL support       no 
SDL image support no
GTK support       no 
GTK GL support    no
VTE support       no 
TLS priority      NORMAL
GNUTLS support    yes
libgcrypt         no
nettle            yes (2.7.1)
libtasn1          yes
PAM               no
iconv support     yes
curses support    no
virgl support     no 
curl support      yes
mingw32 support   no
Audio drivers     pa oss
Block whitelist (rw) 
Block whitelist (ro) 
VirtFS support    
Multipath support 
VNC support       yes
VNC SASL support  no
VNC JPEG support  yes
VNC PNG support   yes
xen support       no
brlapi support    no
bluez  support    no
Documentation     no
PIE               yes
vde support       no
netmap support    no
Linux AIO support yes
ATTR/XATTR support yes
Install blobs     yes
KVM support       yes
HAX support       no
HVF support       no
WHPX support      no
TCG support       yes
TCG debug enabled no
TCG interpreter   no
malloc trim support yes
RDMA support      no
PVRDMA support    no
fdt support       git
membarrier        no
preadv support    yes
fdatasync         yes
madvise           yes
posix_madvise     yes
posix_memalign    yes
libcap-ng support no
vhost-net support yes
vhost-crypto support yes
vhost-scsi support yes
vhost-vsock support yes
vhost-user support yes
Trace backends    log
spice support     no 
rbd support       no
xfsctl support    no
smartcard support no
libusb            yes
usb net redir     no
OpenGL support    no
OpenGL dmabufs    no
libiscsi support  no
libnfs support    no
build guest agent yes
QGA VSS support   no
QGA w32 disk info no
QGA MSI support   no
seccomp support   no
coroutine backend ucontext
coroutine pool    yes
debug stack usage no
mutex debugging   no
crypto afalg      no
GlusterFS support no
gcov              gcov
gcov enabled      no
TPM support       yes
libssh support    no
QOM debugging     yes
Live block migration yes
lzo support       no
snappy support    no
bzip2 support     yes
lzfse support     no
NUMA host support yes
libxml2           yes
tcmalloc support  no
jemalloc support  no
avx2 optimization yes
replication support yes
VxHS block device no
bochs support     yes
cloop support     yes
dmg support       yes
qcow v1 support   yes
vdi support       yes
vvfat support     yes
qed support       yes
parallels support yes
sheepdog support  yes
capstone          git
docker            no
libpmem support   no
libudev           yes
default devices   yes

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__ } },
                       ^
/home/armbru/qemu/rules.mak:69: recipe for target 'linux-user/syscall.o' failed
make[1]: *** [linux-user/syscall.o] Error 1
Makefile:472: recipe for target 'i386-linux-user/all' failed
make: *** [i386-linux-user/all] Error 2

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

[Peter Maydell]

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

thanks
-- PMM

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

[Peter Maydell]

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

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

[Aleksandar Markovic]

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

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

[Michael Tokarev]

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.
[]

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

[Daniel P. Berrangé]

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 :|

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

[Peter Maydell]

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

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

[Aleksandar Markovic]

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 :|
>
>

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

[Peter Maydell]

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