1. 18 6月, 2018 1 次提交
  2. 09 6月, 2018 1 次提交
  3. 05 6月, 2018 2 次提交
  4. 01 6月, 2018 3 次提交
  5. 29 5月, 2018 1 次提交
  6. 19 5月, 2018 1 次提交
  7. 11 5月, 2018 2 次提交
    • P
      configure: Display if libfdt is from system or git · e3971d61
      Philippe Mathieu-Daudé 提交于
      The configure script outputs "yes" regardless which libfdt is used:
      
        ./configure
        [...]
        fdt support       yes
      
      Sometimes you can have both system and local git version available,
      change the configure script to display which library got selected:
      
        debian8$ dpkg-query --showformat='${Version}\n' --show libfdt-dev
        1.4.0+dfsg-1
      
        debian8$ ./configure
        [...]
        fdt support       git
      Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-Id: <20180415230522.24404-3-f4bug@amsat.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      e3971d61
    • P
      configure: Really use local libfdt if the system one is too old · 8a99e9a3
      Philippe Mathieu-Daudé 提交于
      QEMU requires libfdt version >= 1.4.2.
      If the host has an older libfdt installed, the configure script will use
      a (git cloned) local version.
      
      Example with Debian 8:
          $ dpkg-query --showformat='${Version}\n' --show libfdt-dev
          1.4.0+dfsg-1
          $ ./configure
          [...]
          fdt support       yes          # from git submodule 'dtc'
      
      If this case occurs, the linker will have 2 different libfdt available in
      the library search path. The default behavior is to search the system path
      first, then the local path.
      
      Even if the configure script noticed the libfdt is too old and clone a more
      recent locally, when linking the system library is selected first, and the
      link process eventually fails:
      
            LINK    mips64el-softmmu/qemu-system-mips64el
          ../hw/core/loader-fit.o: In function `load_fit':
          /root/src/github.com/philmd/qemu/hw/core/loader-fit.c:278: undefined reference to `fdt_first_subnode'
          /root/src/github.com/philmd/qemu/hw/core/loader-fit.c:286: undefined reference to `fdt_next_subnode'
          /root/src/github.com/philmd/qemu/hw/core/loader-fit.c:277: undefined reference to `fdt_first_subnode'
          collect2: error: ld returned 1 exit status
          Makefile:201: recipe for target 'qemu-system-mips64el' failed
          make[1]: *** [qemu-system-mips64el] Error 1
      
      QEMU already uses a kludge to enforce local CFLAGS before system ones for
      libpixman and libfdt, add a similar kludge for the LDFLAGS to enforce using
      the local libfdt.
      Signed-off-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-Id: <20180415230522.24404-2-f4bug@amsat.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NThomas Huth <thuth@redhat.com>
      8a99e9a3
  8. 09 5月, 2018 2 次提交
  9. 27 4月, 2018 1 次提交
    • M
      ccid-card: include libcacard.h only · 0f5c642d
      Michal Privoznik 提交于
      When trying to build with latest libcacard-2.5.1, I hit the
      following error:
      
      In file included from hw/usb/ccid-card-passthru.c:12:0:
      /usr/include/cacard/vscard_common.h:26:2: error: #warning "Only <libcacard.h> can be included directly" [-Werror=cpp]
       #warning "Only <libcacard.h> can be included directly"
      
      While it was fixed in libcacard upstream (so that individual
      files can be included directly), it doesn't make much sense.
      Let's switch to including the main libcacard.h and also require
      at least libcacard-2.5.1 which introduced it. It's available
      since late 2015.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-id: 3c36db1dc0702763ebb7966cc27428ed67d43804.1522751624.git.mprivozn@redhat.com
      
      [ kraxel: fix include path ]
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      0f5c642d
  10. 26 4月, 2018 3 次提交
  11. 10 4月, 2018 2 次提交
    • P
      configure: don't warn SDL abi if disabled · c6093a05
      Peter Xu 提交于
      SDL has the same problem as GTK that we might get warnings on SDL ABI
      version even if SDL is disabled.  Fix that by only probing SDL if SDL is
      enabled.  Also this should let configure be a little bit faster since we
      don't really need to probe SDL stuff when it's off.
      
      CC: Paolo Bonzini <pbonzini@redhat.com>
      CC: Gerd Hoffmann <kraxel@redhat.com>
      CC: Peter Maydell <peter.maydell@linaro.org>
      CC: Daniel P. Berrange <berrange@redhat.com>
      CC: Fam Zheng <famz@redhat.com>
      CC: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Message-id: 20180410054034.20479-1-peterx@redhat.com
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      c6093a05
    • P
      configure: don't warn GTK if disabled · 5a464e6c
      Peter Xu 提交于
      We don't need to detect GTK ABI if GTK is disabled in general.
      Otherwise we could get this warning (when host is installed with GTK ABI
      version 2) even when configure with "--disable-gtk":
      
          WARNING: Use of GTK 2.0 is deprecated and will be removed in
          WARNING: future releases. Please switch to using GTK 3.0
      
      CC: Paolo Bonzini <pbonzini@redhat.com>
      CC: Gerd Hoffmann <kraxel@redhat.com>
      CC: Peter Maydell <peter.maydell@linaro.org>
      CC: Fam Zheng <famz@redhat.com>
      CC: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
      Signed-off-by: NPeter Xu <peterx@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Message-id: 20180409082323.29575-1-peterx@redhat.com
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      5a464e6c
  12. 09 4月, 2018 1 次提交
  13. 04 4月, 2018 1 次提交
    • L
      tcg: fix 16-byte vector operations detection · 74912f6d
      Laurent Vivier 提交于
      configure tries to detect if the compiler
      supports 16-byte vector operations.
      
      As stated in the comment of the detection
      program, there is a problem with the system
      compiler on GCC on Centos 7.
      
      This program doesn't actually detect the problem
      with GCC on RHEL7 on PPC64LE (Red Hat 4.8.5-28).
      
      This patch updates the test to look more like
      it is in QEMU helpers, and now detects the problem.
      
      The error reported is:
      
        CC      ppc64-softmmu/accel/tcg/tcg-runtime-gvec.o
        ..//accel/tcg/tcg-runtime-gvec.c: In function ‘helper_gvec_shl8i’:
        ../accel/tcg/tcg-runtime-gvec.c:558:26: internal compiler error: in emit_move_insn, at expr.c:3495
                 *(vec8 *)(d + i) = *(vec8 *)(a + i) << shift;
                                  ^
      Fixes: db432672 "tcg: Add generic vector expanders"
      Signed-off-by: NLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: NMiroslav Rezanina <mrezanin@redhat.com>
      Message-id: 20180328133152.24623-1-lvivier@redhat.com
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      74912f6d
  14. 26 3月, 2018 1 次提交
  15. 23 3月, 2018 1 次提交
  16. 14 3月, 2018 1 次提交
  17. 12 3月, 2018 9 次提交
  18. 07 3月, 2018 1 次提交
  19. 06 3月, 2018 3 次提交
  20. 05 3月, 2018 3 次提交