1. 04 Jun, 2018 1 commit
  2. 24 May, 2018 1 commit
  3. 11 May, 2018 1 commit
    • Philippe Mathieu-Daudé's avatar
      configure: Really use local libfdt if the system one is too old · 8a99e9a3
      Philippe Mathieu-Daudé authored
      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
          $ ./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: 's avatarPhilippe Mathieu-Daudé <f4bug@amsat.org>
      Message-Id: <20180415230522.24404-2-f4bug@amsat.org>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: 's avatarThomas Huth <thuth@redhat.com>
  4. 23 Mar, 2018 1 commit
  5. 13 Feb, 2018 1 commit
    • Daniel P. Berrange's avatar
      Revert "build-sys: silence make by default or V=0" · 8cc357b5
      Daniel P. Berrange authored
      This reverts commit 42a77f1c.
      The primary intention of this change was to silence messages
        make[1]: '/home/berrange/src/virt/qemu/capstone/libcapstone.a' is up to date.
      which we get when calling make recursively with explicit
      The problem is that this change affected every make target,
      not merely the targets that triggered these "is up to date"
      messages. As a result any targets that were not invoking
      commands via "$(call quiet-command ...)" suddenly become
      silent. This is particularly bad for "make install" which
      now appears todo nothing.
      Rather than go through every make rule and try to identify
      places where we now need to explicitly print a message to
      show work taking place, just revert the change.
      To address the original problem of silencing "is up to date"
      messages, we simply add --quiet to the SUBDIR_MAKEVARS
      variable, so it only affects us on recursive make calls.
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <20180123164718.12714-2-berrange@redhat.com>
      Tested-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  6. 12 Jan, 2018 1 commit
  7. 15 Jun, 2017 1 commit
  8. 07 Jun, 2017 1 commit
    • Bruno Dominguez's avatar
      configure: split c and cxx extra flags · 11cde1c8
      Bruno Dominguez authored
      There was no possibility to add specific cxx flags using the configure
      file. So A new entrance has been created to support it.
      Duplication of information in configure and rules.mak. Taking
      QEMU_CFLAGS and add them to QEMU_CXXFLAGS, now the value of
      QEMU_CXXFLAGS is stored in config-host.mak, so there is no need for
      The makefile for libvixl was adding flags for QEMU_CXXFLAGS in
      QEMU_CFLAGS because of the addition in rules.mak. That was removed, so
      adding them where it should be.
      Signed-off-by: 's avatarBruno Dominguez <bru.dominguez@gmail.com>
      Reviewed-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-id: 1496754467-20893-1-git-send-email-bru.dominguez@gmail.com
      Signed-off-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
  9. 16 Mar, 2017 1 commit
    • Markus Armbruster's avatar
      qapi: Clean up build of generated documentation · bd7f9747
      Markus Armbruster authored
      Rename intermediate qemu-qapi.texi to qemu-qmp-qapi.texi to match its
      user qemu-qmp-ref.texi, just like qemu-ga-qapi.texi matches
      Build the intermediate .texi next to the sources and the final output
      in docs/ instead of dumping them into the build root.
      Fix version.texi dependencies so that only the targets that actually
      need it depend on it.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Message-Id: <1489582656-31133-8-git-send-email-armbru@redhat.com>
  10. 07 Feb, 2017 1 commit
    • Daniel P. Berrange's avatar
      rules: don't try to create missing include dirs · ac7568bd
      Daniel P. Berrange authored
        commit ba78db44
        Author: Daniel P. Berrange <berrange@redhat.com>
        Date:   Wed Jan 25 16:14:10 2017 +0000
        make: move top level dir to end of include search path
      The dir $(BUILD_DIR)/$(@D) was added to the include
      path. This would sometimes point to a non-existant
      directory, if the sub-dir in question did not contain
      any target-independant files (eg tcg/). To deal with
      this the rules.mak attempted to create the directory.
      While this was succesful, it also caused accidental
      creation of files in the parent of the build dir.
      e.g. when building common source files into target
      specific output files.
      Rather than trying to workaround this, just revert
      the code that attempted to mkdir the missing include
      directories. Instead just turn off the compiler warning
      in question as the missing dir is expected & harmless
      in general.
      NB: you can clean up a build directory parent that has
      been filled with empty directories by commit ba78db44
      using this GNU find command in that parent directory:
        find audio backends block chardev crypto disas fsdev hw io linux-user \
          migration nbd net qapi qom replay slirp target ui util \
          -type d -empty -delete
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Tested-by: 's avatarAlberto Garcia <berto@igalia.com>
      [PMM: added note about how to clean up a polluted directory]
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
  11. 31 Jan, 2017 1 commit
    • Daniel P. Berrange's avatar
      make: move top level dir to end of include search path · ba78db44
      Daniel P. Berrange authored
      Currently the search path is
        1. source dir corresponding to input file (implicit by compiler)
        2. top level build dir
        3. top level source dir
        4. top level source include/ dir
        5. source dir corresponding to input file
        6. build dir corresponding to output file
      Search item 5 is an effective no-op, since it duplicates item 1.
      When srcdir == builddir, item 6 also duplicates item 1, which
      causes a semantic difference between VPATH and non-VPATH builds.
      Thus to ensure consistent semantics we need item 6 to be present
      immediately after item 1. e.g.
        1. source dir corresponding to input file (implicit by compiler)
        2. build dir corresponding to output file
        3. top level build dir
        4. top level source dir
        5. top level source include/ dir
      When srcdir == builddir, items 1 & 2 collapse into one, and items
      3 & 4 collapse into one, but the overall search order is still
      consistent with srcdir != builddir
      A further complication is that while most of the source files
      are built with a current directory of $BUILD_DIR, target dependant
      files are built with a current directory of $BUILD_DIR/$TARGET.
      As a result, search item 2 resolves to a different location for
      target independant vs target dependant files. For example when
      building 'migration/ram.o', the use of '-I$(@D)' (which expands
      to '-Imigration') would not find '$BUILD_DIR/migration', but
      rather '$BUILD_DIR/$TARGET/migration'.
      If there are generated headers files to be used by the migration
      code in '$BUILD_DIR/migration', these will not be found by the
      relative include, an absolute include is needed instead. This
      has not been a problem so far, since nothing has been generating
      headers in sub-dirs, but the trace code will shortly be doing
      that. So it is needed to list '-I$(BUILD_DIR)/$(@D)' as well as
      '-I$(@D)' to ensure both directories are searched when building
      target dependant code. So the search order ends up being:
        1. source dir corresponding to input file (implicit by compiler)
        2. build dir corresponding to output file (absolute)
        3. build dir corresponding to output file (relative to cwd)
        4. top level build dir
        5. top level source dir
        6. top level source include/ dir
      One final complication is that the absolute '-I$(BUILD_DIR)/$(@D)'
      will sometimes end up pointing to a non-existant directory if
      that sub-dir does not have any target-independant files to be
      built. Rather than try to dynamically filter this, a simple
      'mkdir' ensures $(BUILD_DIR)/$(@D) is guaranteed to exist at
      all times.
      Signed-off-by: 's avatarDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Message-id: 20170125161417.31949-2-berrange@redhat.com
      Signed-off-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
  12. 16 Jan, 2017 2 commits
  13. 22 Dec, 2016 2 commits
    • Paolo Bonzini's avatar
      rules.mak: add more rules to avoid chaining · a273f4ce
      Paolo Bonzini authored
      Really rule chaining is not a particularly expensive task, since
      GNU Make caches the directory listing.  However it is easy to
      avoid it for most files and for phony targets (one was missing).
      After this patch, only "Makefile", "scripts/hxtool" and
      "scripts/create_config" attempt to use chained rules.
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
    • Paolo Bonzini's avatar
      rules.mak: speedup save-vars load-vars · 5ffb3505
      Paolo Bonzini authored
      Unnesting variables spends a lot of time parsing and executing foreach
      and if functions.  Because actually very few variables have to be
      saved and restored, a good strategy is to remember what has to be done
      in load-vars, and only iterate the right variables in load-vars.
      For save-vars, unroll the foreach loop to provide another small
      This speeds up a "noop" build from around 15.5 seconds on my laptop
      to 11.7 (25% roughly).
      Reviewed-by: 's avatarFam Zheng <famz@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  14. 29 Nov, 2016 1 commit
    • Paolo Bonzini's avatar
      rules.mak: Also try -r to build modules · 7ecf44a5
      Paolo Bonzini authored
      Building qemu fails in distributions where gcc enables PIE by default
      (e.g. Debian unstable) with:
      /usr/bin/ld: -r and -pie may not be used together
      You have to use -r instead of -Wl,-r to avoid gcc passing -pie to the linker
      when PIE is enabled and a relocatable object is passed.  However, clang
      does not know about -r, so try -Wl,-r first.
      [This is a fix for commit c96f0ee6
      ("rules.mak: Use -r instead of -Wl, -r to fix building when PIE is
      default") which mostly worked but broke the ./configure --enable-modules
      build with clang.
      Reported-by: 's avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Message-id: 20161129153720.29747-1-pbonzini@redhat.com
      Cc: qemu-stable@nongnu.org
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarStefan Hajnoczi <stefanha@redhat.com>
  15. 28 Nov, 2016 1 commit
  16. 08 Oct, 2016 1 commit
  17. 06 Oct, 2016 1 commit
    • Peter Maydell's avatar
      rules.mak: quiet-command: Split command name and args to print · 0bdb12c7
      Peter Maydell authored
      The quiet-command make rule currently takes two arguments:
      the command and arguments to run, and a string to print if
      the V flag is not set (ie we are not being verbose).
      By convention, the string printed is of the form
      "  NAME   some args". Unfortunately to get nicely lined up
      output all the strings have to agree about what column the
      arguments should start in, which means that if we add a
      new quiet-command usage which wants a slightly longer CMD
      name then we either put up with misalignment or change
      every quiet-command string.
      Split the quiet-mode string into two, the "NAME" and
      the "same args" part, and use printf(1) to format the
      string automatically. This means we only need to change
      one place if we want to support a longer maximum name.
      In particular, we can now print 7-character names lined
      up properly (they are needed for the OSX "SETTOOL" invocation).
      Change all the uses of quiet-command to the new syntax.
      (Any which are missed or inadvertently reintroduced
      via later merges will result in slightly misformatted
      quiet output rather than disaster.)
      A few places in the pc-bios/ makefiles are updated to use
      "BUILD", "SIGN" and "STRIP" rather than "Building",
      "Signing" and "Stripping" for consistency and to keep them
      below 7 characters. Module .mo links now print "LD" rather
      than the nonstandard "LD -r".
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Message-id: 1475598441-27908-1-git-send-email-peter.maydell@linaro.org
  18. 13 Sep, 2016 1 commit
    • Fam Zheng's avatar
      rules.mak: Don't extract libs from .mo-libs in link command · 5b1b6dbd
      Fam Zheng authored
      For module build, .mo objects are passed to LINK and consumed in
      process-archive-undefs. The reason behind that is documented in the
      comment above process-archive-undefs.
      Similarly, extract-libs should be called with .mo filtered out too.
      Otherwise, the .mo-libs are added to the link command incorrectly,
      spoiling the purpose of modularization.
      Currently we don't have any .mo-libs usage, but it will be used soon
      when we modularize more multi-source objects, like sdl and gtk.
      Reported-by: 's avatarColin Lord <clord@redhat.com>
      Signed-off-by: 's avatarFam Zheng <famz@redhat.com>
      Message-Id: <1469600777-30413-2-git-send-email-famz@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  19. 06 Sep, 2016 1 commit
    • Michael Mueller's avatar
      s390x/cpumodel: generate CPU feature lists for CPU models · dced7eec
      Michael Mueller authored
      This patch introduces the helper "gen-features" which allows to generate
      feature list definitions at compile time. Its flexibility is better and the
      error-proneness is lower when compared to static programming time added
      The helper includes "target-s390x/cpu_features.h" to be able to use named
      facility bits instead of numbers. The generated defines will be used for
      the definition of CPU models.
      We generate feature lists for each HW generation and GA for EC models. BC
      models are always based on a EC version and have no separate definitions.
      Base features: Features we expect to be always available in sane setups.
      Migration safe - will never change. Can be seen as "minimum features
      required for a CPU model".
      Default features: Features we expect to be stable and around in latest
      setups (e.g. having KVM support) - not migration safe.
      Max features: All supported features that are theoretically allowed for a
      CPU model. Exceeding these features could otherwise produce problems with
      IBC (instruction blocking controls) in KVM.
      Acked-by: 's avatarCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: 's avatarMichael Mueller <mimu@linux.vnet.ibm.com>
      Signed-off-by: 's avatarDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      [generate base, default and models. renaming and cleanup]
      Message-Id: <20160905085244.99980-6-dahi@linux.vnet.ibm.com>
      Signed-off-by: 's avatarCornelia Huck <cornelia.huck@de.ibm.com>
  20. 29 Jul, 2016 1 commit
  21. 10 Jul, 2016 1 commit
  22. 06 Jul, 2016 1 commit
    • Richard Henderson's avatar
      build: Use $(CCAS) for compiling .S files · 5f6f0e27
      Richard Henderson authored
      We fail to pass to $(AS) all of the different flags that may be required
      for a given set of CFLAGS.  Rather than figuring out the host-specific
      mapping, it's better to allow the compiler driver to do that.
      However, simply using $(CC) runs afoul of clang trying to build the
      option roms.  C.f. 3dd46c78, wherein we changed from
      using $(CC) to using $(AS) in the first place.
      Work around this by passing -fno-integrated-as to clang, so that we use
      the external assembler, and the clang driver still passes along all of
      the options that the assembler might require.
      Reviewed-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: 's avatarRichard Henderson <rth@twiddle.net>
      Message-Id: <1466703558-7723-1-git-send-email-rth@twiddle.net>
  23. 07 Jun, 2016 2 commits
  24. 01 Jun, 2016 1 commit
  25. 17 Feb, 2016 1 commit
  26. 11 Feb, 2016 1 commit
  27. 13 Aug, 2015 2 commits
  28. 08 May, 2015 1 commit
    • Fam Zheng's avatar
      rules.mak: Force CFLAGS for all objects in DSO · d24697e1
      Fam Zheng authored
      Because of the trick of process-archive-undefs, all .mo objects, even
      with --enable-modules, are dependencies of executables.
      This breaks CFLAGS propogation because the compiling of module object
      will happen too early before building for DSO.
      With GCC 5, the linking would fail because .o doesn't have -fPIC. Also,
      BUILD_DSO will be missed. (module-common.o will have it, so the stamp
      symbol was still liked in .so).
      Fix the problem by forcing the CFLAGS on individual .o-cflags during
      Reported-by: 's avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: 's avatarFam Zheng <famz@redhat.com>
      Cc: qemu-stable@nongnu.org # 2.3
      Message-Id: <1430981715-31465-1-git-send-email-famz@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  29. 14 Jan, 2015 1 commit
  30. 31 Oct, 2014 1 commit
  31. 19 Sep, 2014 1 commit
  32. 09 Sep, 2014 1 commit
    • Fam Zheng's avatar
      rules.mak: Fix DSO build by pulling in archive symbols · c261d774
      Fam Zheng authored
      This fixes an issue with module build system. block/iscsi.so is
      currently broken:
          $ ~/build/last/qemu-img
          Failed to open module: /home/fam/build/master/block-iscsi.so:
          undefined symbol: qmp_query_uuid
          qemu-img: Not enough arguments
          Try 'qemu-img --help' for more information
      To fix this, we should (at least) let qemu-img link qmp_query_uuid from
      libqemustub.a. (There are a few other symbols missing, as well.)
      This patch changes the linking rules to:
      1) Build ".mo" with "ld -r -o $@ $^" for each ".so", and later build .so
         with it.
      2) Always build all the .mo before linking the executables. This is
         achieved by adding those .mo files to the executables' "-y"
      3) When linking an executable, those .mo files in its "-y" variables are
         filtered out, and replaced by one or more -Wl,-u,$symbol flags. This
         is done in the added macro "process-archive-undefs".
         These "-Wl,-u,$symbol" flags will force ld to pull in the function
         definition from the archives when linking.
         Note that the .mo objects, that are actually meant to be linked in
         the executables, are already expanded in unnest-vars, before the
         linking command. So we are safe to simply filter out .mo for the
         purpose of pulling undefined symbols.
         process-archive-undefs works as this: For each ".mo", find all the
         undefined symbols in it, filter ones that are defined in the
         archives. For each of these symbols, generate a "-Wl,-u,$symbol" in
         the link command, and put them before archive names in the command
      Suggested-by: 's avatarH.J. Lu <hjl.tools@gmail.com>
      Signed-off-by: 's avatarFam Zheng <famz@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  33. 24 Jun, 2014 1 commit
  34. 16 Jun, 2014 1 commit
  35. 10 Jun, 2014 1 commit
    • Fam Zheng's avatar
      rules.mak: Rewrite unnest-vars · 1c33ac57
      Fam Zheng authored
      The macro unnest-vars is the most important, complicated but hard to
      track magic in QEMU's build system.
      Rewrite it in a (hopefully) clearer way, with more comments, to make it
      easier to understand and maintain.
      Remove DSO_CFLAGS and module-objs-m that are not used.
      A bonus fix of this version is, per object variables are properly
      protected in save-objs and load-objs, before including sub-dir
      Makefile.objs, just as nested variables are. So the occasional same
      object name from different directory levels won't step on each other's
      Signed-off-by: 's avatarFam Zheng <famz@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
  36. 09 May, 2014 1 commit
    • Paolo Bonzini's avatar
      build: simplify and fix fix-obj-vars · 2a8e6c7a
      Paolo Bonzini authored
      fix-obj-vars has the undesired side effect of breaking -cflags
      -objs and -libs variables in the toplevel Makefile.objs.  The
      variables in the toplevel Makefile.objs do not need any fix,
      so fix-obj-vars need not do anything.
      Since we are touching it, remove the now unnecessary $(if)
      in the callers.
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>