1. 11 2月, 2016 1 次提交
  2. 10 2月, 2016 1 次提交
  3. 09 2月, 2016 1 次提交
    • D
      configure: sanity check the glib library that pkg-config finds · 977a82ab
      Daniel P. Berrange 提交于
      Developers on 64-bit machines will often try to perform a
      32-bit build of QEMU by running
      
        ./configure --extra-cflags="-m32"
      
      Unfortunately if PKG_CONFIG_LIBDIR is not set to point to
      the location of the 32-bit pkg-config files, then configure
      will silently pick up the 64-bit pkg-config files and still
      succeed.
      
      This causes a problem for glib because it means QEMU will
      be pulling in /usr/lib64/glib-2.0/include/glibconfig.h
      instead of /usr/lib/glib-2.0/include/glibconfig.h
      
      This causes problems because the 'gsize' type (defined as
      'unsigned long') will no longer be fully compatible with
      the 'size_t' type (defined as 'unsigned int'). Although
      both are the same size, the compiler refuses to allow
      casts from 'unsigned long *' to 'unsigned int *' as they
      are different pointer types. This results in non-obvious
      compiler errors when building QEMU eg
      
      qga/commands-posix.c: In function ‘qmp_guest_set_user_password’:
      qga/commands-posix.c:1912:55: error: passing argument 2 of ‘g_base64_decode’ from incompatible pointer type [-Werror=incompatible-pointer-types]
           rawpasswddata = (char *)g_base64_decode(password, &rawpasswdlen);
                                                                  ^
      In file included from /usr/include/glib-2.0/glib.h:35:0,
                       from qga/commands-posix.c:14:
      /usr/include/glib-2.0/glib/gbase64.h:52:9: note: expected ‘gsize * {aka long unsigned int *}’ but argument is of type ‘size_t * {aka unsigned int *}’
       guchar *g_base64_decode         (const gchar  *text,
               ^
      cc1: all warnings being treated as errors
      
      To detect this problem, add a check to configure that
      verifies that GLIB_SIZEOF_SIZE_T matches sizeof(size_t).
      If this fails print a warning suggesting that the dev
      probably needs to set PKG_CONFIG_LIBDIR.
      
      On Fedora x86_64 it passes with any of:
      
       # ./configure
       # PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig ./configure --extra-cflags="-m32"
       # PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig ./configure --extra-cflags="-m64"
      
      And fails with a mis-match
      
       # PKG_CONFIG_LIBDIR=/usr/lib64/pkgconfig ./configure --extra-cflags="-m32"
       # PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig ./configure --extra-cflags="-m64"
      
      ERROR: sizeof(size_t) doesn't match GLIB_SIZEOF_SIZE_T.
             You probably need to set PKG_CONFIG_LIBDIR
             to point to the right pkg-config files for your
             build target
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1453885245-15562-1-git-send-email-berrange@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      977a82ab
  4. 03 2月, 2016 2 次提交
  5. 30 1月, 2016 1 次提交
  6. 27 1月, 2016 2 次提交
  7. 11 1月, 2016 1 次提交
  8. 18 12月, 2015 2 次提交
    • P
      configure: Fix shell syntax to placate OpenBSD's pdksh · 18f49881
      Peter Maydell 提交于
      Unfortunately the OpenBSD pdksh does not like brackets inside
      the right part of a ${variable+word} parameter expansion:
      
        $ echo "${a+($b)}"
        ksh: ${a+($b)}": bad substitution
      
      though both bash and dash accept them. In any case this line
      was causing odd output in the case where nettle is not present:
        nettle    no ()
      
      (because if nettle is not present then $nettle will be "no",
      not a null string or unset).
      
      Rewrite it to just use an if.
      
      This bug was originally introduced in becaeb72 and was present
      in the 2.4.0 release.
      
      Fixes: https://bugs.launchpad.net/qemu/+bug/1525682
      Reported-by: Dmitrij D. Czarkoff
      Cc: qemu-stable@nongnu.org
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 1450105357-8516-1-git-send-email-peter.maydell@linaro.org
      18f49881
    • D
      io: add QIOChannelSocket class · 559607ea
      Daniel P. Berrange 提交于
      Implement a QIOChannel subclass that supports sockets I/O.
      The implementation is able to manage a single socket file
      descriptor, whether a TCP/UNIX listener, TCP/UNIX connection,
      or a UDP datagram. It provides APIs which can listen and
      connect either asynchronously or synchronously. Since there
      is no asynchronous DNS lookup API available, it uses the
      QIOTask helper for spawning a background thread to ensure
      non-blocking operation.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      559607ea
  9. 04 12月, 2015 2 次提交
    • R
      configure: use appropriate code fragment for -fstack-protector checks · fccd35a0
      Rodrigo Rebello 提交于
      The check for stack-protector support consisted in compiling and linking
      the test program below (output by function write_c_skeleton()) with the
      compiler flag -fstack-protector-strong first and then with
      -fstack-protector-all if the first one failed to work:
      
        int main(void) { return 0; }
      
      This caused false positives when using certain toolchains in which the
      compiler accepted -fstack-protector-strong but no support was provided
      by the C library, since for this stack-protector variant the compiler
      emits canary code only for functions that meet specific conditions
      (local arrays, memory references to local variables, etc.) and the code
      fragment under test included none of them (hence no stack protection
      code generated, no link failure).
      
      This fix changes the test program used for -fstack-protector checks to
      include a function that meets conditions which cause the compiler to
      generate canary code in all variants.
      Signed-off-by: NRodrigo Rebello <rprebello@gmail.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      fccd35a0
    • P
      configure: Diagnose broken linkers directly · 0ef74c74
      Peter Maydell 提交于
      Currently if the user's compiler works for creating .o files but
      their linker is broken such that compiling an executable from a
      C file does not work, we will report a misleading error message
      about the compiler not supporting __thread (since that happens
      to be the first test we run which requires a working linker).
      Explicitly check that compile_prog works as well as compile_object,
      so that people whose toolchain setup is broken get a more helpful
      error message.
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
      0ef74c74
  10. 30 11月, 2015 1 次提交
  11. 19 11月, 2015 1 次提交
  12. 16 11月, 2015 2 次提交
  13. 14 11月, 2015 1 次提交
  14. 13 11月, 2015 1 次提交
  15. 10 11月, 2015 1 次提交
  16. 06 11月, 2015 2 次提交
  17. 05 11月, 2015 1 次提交
    • J
      configure: disable FORTIFY_SOURCE under clang · b553a042
      John Snow 提交于
      Some versions of clang may have difficulty compiling glibc headers when
      -D_FORTIFY_SOURCE is used. For example, Clang++ 3.5.0-9.fc22 cannot
      compile glibc's stdio headers when -D_FORTIFY_SOURCE=2 is used. This
      manifests currently as build failures with clang and any arm target.
      
      According to LLVM dev Richard Smith, clang does not target or support
      FORTIFY_SOURCE + glibc, and it should not be relied on.
      "It's still an unsupported combination, and while it might compile, some
      of the checks are unlikely to work because they require a frontend
      inliner to be useful"
      
      See: http://lists.llvm.org/pipermail/cfe-dev/2015-November/045846.html
      
      Conclusion: disable fortify-source if we appear to be using clang instead
      of testing for compile success or failure, which may be incidental or not
      indicative of proper support of the feature.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-Id: <1446583422-10153-1-git-send-email-jsnow@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b553a042
  18. 04 11月, 2015 1 次提交
    • J
      configure: disallow ccache during compile tests · 5e4dfd3d
      John Snow 提交于
      If the user is using ccache during the configuration step,
      it may interfere with some of the configuration tests,
      particularly the "Is ccache interfering with macro analysis" step,
      which is a bit of a poetic problem.
      
      1) Disallow ccache from reading from the cache during configure,
         but don't disable it entirely to allow us to see if it causes other
         problems.
      
      2) Force off CCACHE_CPP2 during the ccache test to get a deterministic
         answer over whether or not we need to enable that feature later.
      Signed-off-by: NJohn Snow <jsnow@redhat.com>
      Message-Id: <1446055000-29150-1-git-send-email-jsnow@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      5e4dfd3d
  19. 03 11月, 2015 1 次提交
    • O
      ui/opengl: Reduce build required libraries for opengl · fb719563
      OGAWA Hirofumi 提交于
      We now use epoxy to load opengl libraries. This means we don't need to
      link opengl libraries directly if interfaces handled by epoxy. With
      this, we just need epoxy headers and epoxy's *.so to build.
      
      Tested with epoxy-1.3.1.
      
      - sdl2/gtk/console egl stuff doesn't require other than epoxy
      - milkymist-tmu2 glx stuff doesn't require other than epoxy
      
      (lm32 test is limited, because can't find mmone-bios.bin, so just test
      to load libGL with "./lm32-softmmu/qemu-system-lm32 -M milkymist,accel=qtest")
      Signed-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      
      [ lm32 tested by kraxel ]
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      fb719563
  20. 25 10月, 2015 1 次提交
  21. 23 10月, 2015 2 次提交
    • D
      configure: avoid polluting global CFLAGS with tasn1 flags · 90246037
      Daniel P. Berrange 提交于
      The previous commit
      
        commit 9a2fd434
        Author: Daniel P. Berrange <berrange@redhat.com>
        Date:   Mon Apr 13 14:01:39 2015 +0100
      
          crypto: add sanity checking of TLS x509 credentials
      
      defined new variables $TEST_LIBS and $TEST_CFLAGS and
      used them in tests/Makefile to augment $LIBS and $CFLAGS.
      
      Unfortunately this overlooks the fact that tests/Makefile
      is not executed via recursive-make, it is just pulled into
      the top level Makefile via an include statement. So rather
      than just augmenting the compiler/linker flags for tests
      it polluted the global flags.
      
      This is thought to be behind a reported failure when
      building the pixman module as a sub-module, since global
      $CFLAGS are passed down to configure in pixman.
      
      This change removes the $TEST_LIBS and $TEST_CFLAGS
      replacing them with $TASN1_LIBS and $TASN1_CFLAGS,
      setting only against specific objects/executables
      that need them.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      90246037
    • D
      crypto: allow use of nettle/gcrypt to be selected explicitly · 91bfcdb0
      Daniel P. Berrange 提交于
      Currently the choice of whether to use nettle or gcrypt is
      made based on what gnutls is linked to. There are times
      when it is desirable to be able to force build against a
      specific library. For example, if testing changes to QEMU's
      crypto code all 3 possible backends need to be checked
      regardless of what the local gnutls uses.
      
      It is also desirable to be able to enable nettle/gcrypt
      for cipher/hash algorithms, without enabling gnutls
      for TLS support.
      
      This gives two new configure flags, which allow the
      following possibilities
      
      Automatically determine nettle vs gcrypt from what
      gnutls links to (recommended to minimize number of
      crypto libraries linked to)
      
       ./configure
      
      Automatically determine nettle vs gcrypt based on
      which is installed
      
       ./configure --disable-gnutls
      
      Force use of nettle
      
       ./configure --enable-nettle
      
      Force use of gcrypt
      
       ./configure --enable-gcrypt
      
      Force use of built-in AES & crippled-DES
      
       ./configure --disable-nettle --disable-gcrypt
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      91bfcdb0
  22. 22 10月, 2015 1 次提交
  23. 20 10月, 2015 1 次提交
    • M
      build: qemu-ga: add 'qemu-ga' build target for w32 · fafcaf1d
      Michael Roth 提交于
      Currently POSIX builds rely on 'qemu-ga' target to do qga-only
      distributable build. On w32, as with most standalone binary targets,
      we rely on 'qemu-ga.exe' target.
      
      Unlike with POSIX, qemu-ga for w32 has a number of related targets
      such as VSS DLL and MSI package. We can do the full distributable
      qga-only build on w32 with:
      
        make qemu-ga.exe
      
      or:
      
        make msi
      
      To make that work, we tie VSS dependencies onto qemu-ga.exe.
      However, in reality the DLL isn't part of the binary, so we use a
      filter to pull them out of the LINK recipe, which attempts to link
      against prereqs for binary targets. Additionally, it could be argued
      that VSS is a separate distributable, and shouldn't be implied by
      qemu-ga.exe binary target.
      
      To avoid this, we can tie the VSS dependencies only to the 'msi'
      target, but that would make it impossible to do a qga-only build of
      the w32 distributable without building the 'msi' package, which was
      supported in the past.
      
      An alternative approach is to add a new target to build the whole
      distributable. w32 allows us to use the same build target we use
      on POSIX, 'qemu-ga', since the current binary-only target on w32
      is 'qemu-ga.exe'.
      
      To further simplify the build, we also make 'qemu-ga' build the MSI
      package if the appropriate ./configure options are set, making the
      full qga-only build the same on both POSIX and w32: `make qemu-ga`
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com>
      fafcaf1d
  24. 13 10月, 2015 1 次提交
  25. 08 10月, 2015 2 次提交
  26. 02 10月, 2015 1 次提交
  27. 25 9月, 2015 1 次提交
    • D
      oslib-win32: only provide localtime_r/gmtime_r if missing · 4d9310f4
      Daniel P. Berrange 提交于
      The oslib-win32 file currently provides a localtime_r and
      gmtime_r replacement unconditionally. Some versions of
      Mingw-w64 would provide crude macros for localtime_r/gmtime_r
      which QEMU takes care to disable. Latest versions of Mingw-w64
      now provide actual functions for localtime_r/gmtime_r, but
      with a twist that you have to include unistd.h or pthread.h
      before including time.h.  By luck some files in QEMU have
      such an include order, resulting in compile errors:
      
        CC    util/osdep.o
      In file included from include/qemu-common.h:48:0,
                       from util/osdep.c:48:
      include/sysemu/os-win32.h:77:12: error: redundant redeclaration of 'gmtime_r' [-Werror=redundant-decls]
       struct tm *gmtime_r(const time_t *timep, struct tm *result);
                  ^
      In file included from include/qemu-common.h:35:0,
                       from util/osdep.c:48:
      /usr/i686-w64-mingw32/sys-root/mingw/include/time.h:272:107: note: previous definition of 'gmtime_r' was here
      In file included from include/qemu-common.h:48:0,
                       from util/osdep.c:48:
      include/sysemu/os-win32.h:79:12: error: redundant redeclaration of 'localtime_r' [-Werror=redundant-decls]
       struct tm *localtime_r(const time_t *timep, struct tm *result);
                  ^
      In file included from include/qemu-common.h:35:0,
                       from util/osdep.c:48:
      /usr/i686-w64-mingw32/sys-root/mingw/include/time.h:269:107: note: previous definition of 'localtime_r' was here
      
      This change adds a configure test to see if localtime_r
      exits, and only enables the QEMU impl if missing. We also
      re-arrange qemu-common.h try attempt to guarantee that all
      source files get unistd.h before time.h and thus see the
      localtime_r/gmtime_r defs.
      
      [sw: Use "official" spellings for Mingw-w64, MinGW in comments.]
      [sw: Terminate sentences with a dot in comments.]
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NStefan Weil <sw@weilnetz.de>
      4d9310f4
  28. 24 9月, 2015 1 次提交
  29. 15 9月, 2015 3 次提交
    • C
      target-tilegx: Add TILE-Gx building files · 444e06b1
      Chen Gang 提交于
      Add related configuration and make files for tilegx.
      The target can now build, though not run anything.
      Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
      Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
      Message-Id: <BLU436-SMTP1588E5A03AD5E94B07E988B9660@phx.gbl>
      Signed-off-by: NRichard Henderson <rth@twiddle.net>
      444e06b1
    • D
      ui: convert VNC server to use QCryptoTLSSession · 3e305e4a
      Daniel P. Berrange 提交于
      Switch VNC server over to using the QCryptoTLSSession object
      for the TLS session. This removes the direct use of gnutls
      from the VNC server code. It also removes most knowledge
      about TLS certificate handling from the VNC server code.
      This has the nice effect that all the CONFIG_VNC_TLS
      conditionals go away and the user gets an actual error
      message when requesting TLS instead of it being silently
      ignored.
      
      With this change, the existing configuration options for
      enabling TLS with -vnc are deprecated.
      
      Old syntax for anon-DH credentials:
      
        -vnc hostname:0,tls
      
      New syntax:
      
        -object tls-creds-anon,id=tls0,endpoint=server \
        -vnc hostname:0,tls-creds=tls0
      
      Old syntax for x509 credentials, no client certs:
      
        -vnc hostname:0,tls,x509=/path/to/certs
      
      New syntax:
      
        -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=no \
        -vnc hostname:0,tls-creds=tls0
      
      Old syntax for x509 credentials, requiring client certs:
      
        -vnc hostname:0,tls,x509verify=/path/to/certs
      
      New syntax:
      
        -object tls-creds-x509,id=tls0,dir=/path/to/certs,endpoint=server,verify-peer=yes \
        -vnc hostname:0,tls-creds=tls0
      
      This aligns VNC with the way TLS credentials are to be
      configured in the future for chardev, nbd and migration
      backends. It also has the benefit that the same TLS
      credentials can be shared across multiple VNC server
      instances, if desired.
      
      If someone uses the deprecated syntax, it will internally
      result in the creation of a 'tls-creds' object with an ID
      based on the VNC server ID. This allows backwards compat
      with the CLI syntax, while still deleting all the original
      TLS code from the VNC server.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      3e305e4a
    • D
      crypto: add sanity checking of TLS x509 credentials · 9a2fd434
      Daniel P. Berrange 提交于
      If the administrator incorrectly sets up their x509 certificates,
      the errors seen at runtime during connection attempts are very
      obscure and difficult to diagnose. This has been a particular
      problem for people using openssl to generate their certificates
      instead of the gnutls certtool, because the openssl tools don't
      turn on the various x509 extensions that gnutls expects to be
      present by default.
      
      This change thus adds support in the TLS credentials object to
      sanity check the certificates when QEMU first loads them. This
      gives the administrator immediate feedback for the majority of
      common configuration mistakes, reducing the pain involved in
      setting up TLS. The code is derived from equivalent code that
      has been part of libvirt's TLS support and has been seen to be
      valuable in assisting admins.
      
      It is possible to disable the sanity checking, however, via
      the new 'sanity-check' property on the tls-creds object type,
      with a value of 'no'.
      
      Unit tests are included in this change to verify the correctness
      of the sanity checking code in all the key scenarios it is
      intended to cope with. As part of the test suite, the pkix_asn1_tab.c
      from gnutls is imported. This file is intentionally copied from the
      (long since obsolete) gnutls 1.6.3 source tree, since that version
      was still under GPLv2+, rather than the GPLv3+ of gnutls >= 2.0.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      9a2fd434
  30. 10 9月, 2015 1 次提交