Our rule right now is to use <> for external headers,
"" for internal ones. The idea was to avoid conflicts
between e.g. a system file named <trace.h> and an
internal one by the same name.

Unfortunately we use -I compiler flag so it does not
help: a system file doing #include <trace.h> will
still pick up ours first.

To fix, switch to -iquote which is supported by both
gcc and clang and only affects #include "" directives.

As a side effect, this catches any future uses of
 #include <> for internal headers.
Suggested-by: NStefan Weil <sw@weilnetz.de>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>

This reverts commit 42a77f1c.

The primary intention of this change was to silence messages
like

  make[1]: '/home/berrange/src/virt/qemu/capstone/libcapstone.a' is up to date.

which we get when calling make recursively with explicit
targets.

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: NDaniel P. Berrange <berrange@redhat.com>
Message-Id: <20180123164718.12714-2-berrange@redhat.com>
Tested-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Move generic make flags in MAKEFLAGS (SUBDIR_MAKEFLAGS is more qemu specific).

Use --quiet to silence make 'is up to date' message.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20180104160523.22995-3-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This is for the future interoperability & management guide.  It includes
the QAPI docs, including the automatically generated ones, other socket
protocols (vhost-user, VNC), and the qcow2 file format.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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

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: NBruno Dominguez <bru.dominguez@gmail.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-id: 1496754467-20893-1-git-send-email-bru.dominguez@gmail.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

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
qemu-ga-ref.texi.

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: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-Id: <1489582656-31133-8-git-send-email-armbru@redhat.com>

In

  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: NDaniel P. Berrange <berrange@redhat.com>
Tested-by: NAlberto Garcia <berto@igalia.com>
[PMM: added note about how to clean up a polluted directory]
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

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: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 20170125161417.31949-2-berrange@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

Generate and install the man, txt and html versions of QAPI
documentation (generate and install qemu-doc.txt too).

Add it also to optional pdf/info targets.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20170113144135.5150-22-marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

The recipe for making a man page from .texi is duplicated several
times over.  Capture it in suitable pattern rules instead.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20170113144135.5150-20-marcandre.lureau@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

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: NPaolo Bonzini <pbonzini@redhat.com>

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

This speeds up a "noop" build from around 15.5 seconds on my laptop
to 11.7 (25% roughly).
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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.
--Stefan]
Reported-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 20161129153720.29747-1-pbonzini@redhat.com
Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

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

Use -r instead of -Wl,-r to avoid gcc passing -pie to the linker
when PIE is enabled and a relocatable object is passed.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Message-Id: <20161127162817.15144-1-bunk@stusta.de>
Cc: qemu-stable@nongnu.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Fix spelling, the GNU make text functions is not called "find-string"
but "findstring".

Broken in commit 2b2e59e6.  Fairly harmless: its only use is in
tests/tcg/Makefile, where the bug can cause the I386_TESTS not to
run when they should.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

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: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1475598441-27908-1-git-send-email-peter.maydell@linaro.org

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: NColin Lord <clord@redhat.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-Id: <1469600777-30413-2-git-send-email-famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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

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: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NMichael Mueller <mimu@linux.vnet.ibm.com>
Signed-off-by: NDavid 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: NCornelia Huck <cornelia.huck@de.ibm.com>

The cc-option macro runs $(CC) in -S mode (generate assembly) to avoid a
pointless run of the assembler.  However, this does not work when you want
to detect support for cc->as option passthrough.  clang ignores -Wa unless
-c is provided, and exits successfully even if the -Wa,-32 option is not
supported.
Reported-by: NStefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1469043409-14033-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

For clang before 3.5, -fno-integrated-as does not exist,
so the workaround in 5f6f0e27 fails to build.

Use clang's default assembler for linux-user/safe-syscall.S,
and explicitly change to use the system assembler for the
option roms.
Tested-by: NAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: NAlex Bennée <alex.bennee@linaro.org>
Signed-off-by: NRichard Henderson <rth@twiddle.net>

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: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NRichard Henderson <rth@twiddle.net>
Message-Id: <1466703558-7723-1-git-send-email-rth@twiddle.net>

On Sparc, gcc implicitly passes --relax to the linker, but -r is
incompatible with this. Therefore, if --no-relax is supported, it should
be passed to the linker.
Signed-off-by: NJames Clarke <jrtc27@jrtc27.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Make sure that config-host.h and config-target.h are rebuilt whenever
there is a change in the scripts that generates them; add the dependency
to the pattern rule as suggested by Peter.
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Using "," literal in $(call quiet-command, ...) arguments is awkward.
Add this constant to make it at least doable.
Signed-off-by: NFam Zheng <famz@redhat.com>
Message-id: 1464755128-32490-3-git-send-email-famz@redhat.com

It's often handy to make executables depend on each other, e.g. make a
test depend on a helper. This doesn't work now, as linker
will attempt to use the helper as an object.
To fix, filter only relevant file types before linking an executable.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Libtool support was needed to build shared library for libcacard.
Now there's no need to use libtool, and since the build system is
already complicated enough, we have a way to slightly de-complicate
it.
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>
Reviewed-by: NGreg Kurz <gkurz@linux.vnet.ibm.com>

The old rules.mak loads dependency .d files using include directive
with file glob pattern "*.d". This breaks the build when build tree has
left-over *.d files from another build.

This patch fixes this by
  - loading precise list of .d files made from *.o and *.mo.
  - specifying explicit list of required dependency info files for
     *.hex autogenerated sources.

Note that Makefile still includes some .d in root directory by including
"*.d".
Signed-off-by: NVictor Kaplansky <victork@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

In rules like "bar/%.o: %.c" there is a difference between $(*D) and
$(@D). $(*D) expands to '.', while $(@D) expands to 'bar'.  It is
cleaner to generate *.d in the same directory where appropriate *.o
resides. This allows precise including of dependency info from .d files.

As a hack, we also touch two sources for generated *.hex files.  Without
this hack, anyone doing "git pull; make" will not get *.hex rebuilt
correctly since the dependency file would be missing.
Signed-off-by: NVictor Kaplansky <victork@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

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
unnest-vars.
Reported-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NFam 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: NPaolo Bonzini <pbonzini@redhat.com>

Module build is broken since commit c261d774 ( rules.mak: Fix DSO
build by pulling in archive symbols). That commit added .mo placeholders
of DSO to -y variables, in order to pull stub symbols to executable. But
the placeholders are unintentionally expanded in -y, rather than
filtered out while linking.

Fix it by moving the -objs expanding to before inserting .mo
placeholders.  Note that passing -cflags and -libs to member objects are
also moved to keep it happening before object expanding.
Reported-by: NBharata B Rao <bharata.rao@gmail.com>
Tested-by: NBharata B Rao <bharata.rao@gmail.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Expand %.mo-objs in -y nested objects, so that we can write combined
object -cflags rules like what will be done in the coming patch.
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit c261d774 added one more binutils
tool: nm also needs a cross prefix.
Signed-off-by: NStefan Weil <sw@weilnetz.de>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1411070108-8954-1-git-send-email-sw@weilnetz.de
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

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

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
   line.
Suggested-by: NH.J. Lu <hjl.tools@gmail.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Use common rule (macro) to install and strip binaries, and use
it in all places where we install binaries, instead of fixing
bugs like 1319493 in every place.
(This fixes https://bugs.launchpad.net/bugs/1319493)
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Duplicate removal was added to extract-libs in order to avoid including
the same library multiple times into the linking command line; this could
potentially happen when using "foo.mo-libs" (which adds the library to
all components, causing it to appear N times if the module is composed
of N objects).  However, sorting and removing duplicates causes problems
with static linking, and also with space-separated linker options as
found in some Mac OS X packaging systems.  Furthermore, the "optimization"
is really a non-problem since we do not expect .mo modules to be composed
of many files.
Reported-by: NSean Bruno <sbruno@ignoranthack.me>
Tested-by: NSean Bruno <sbruno@ignoranthack.me>
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1402929805-16836-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

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
foot.
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

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: NPaolo Bonzini <pbonzini@redhat.com>

This is needed in order to use per-object flags variables.
Reviewed-by: NMichael Tokarev <mjt@tls.msk.ru>
Reviewed-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The compiling is done in a subdir, so the extraction of per-object libs
and cflags are referencing objects with ../ prefixed. So prefix the
per-object variables "foo.o-cflags" and "foo.o-libs" to
"../foo.o-cflags" and "../foo.o-libs".
Signed-off-by: NFam Zheng <famz@redhat.com>
Reviewed-by: NMichael Tokarev <mjt@tls.msk.ru>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Don't sort the extracted options, sort the objects.
Reported-by: NChristian Mahnke <cmahnke@googlemail.com>
Signed-off-by: NFam Zheng <famz@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>