qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] Fix guest agent build with simpletrace


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH 1/2] Fix guest agent build with simpletrace
Date: Mon, 29 Aug 2011 14:25:35 -0500
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0

On 08/29/2011 07:28 AM, Stefan Hajnoczi wrote:
On Sun, Aug 28, 2011 at 10:08 PM, Blue Swirl<address@hidden>  wrote:
On Sun, Aug 28, 2011 at 6:13 PM, Lluís<address@hidden>  wrote:
Blue Swirl writes:

On Sat, Aug 27, 2011 at 5:56 PM, Lluís<address@hidden>  wrote:
I sent a patch that should fix it for everybody linking with the tracing
objects:

http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg03150.html

With your patch, there are warnings from linker:
../qemu-timer-common.o: warning: multiple common of `use_rt_clock'
../qemu-timer-common.o: warning: previous common is here

Ah, yes. These extra errors are fixed by the duplicate elimination patch
:)

http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg02987.html

So, you need both to keep it clean.

Using the sort function looks hackish to me. Maybe the linkage should
be controlled by configure instead?

What do you mean? Moving the logic for selecting the object files to
link with on each top-level target out into the configure?

Add CONFIG_QEMU_TIMER, configure sets it to 'y' when it is needed by
simpletrace or other cases.

The $(sort) approach is simpler because it is implicit.  I'm not sure
that explicitly managing these dependencies is necessary.  But the

It also mirrors how most projects handle duplicate header includes using a guard.

Plus, it really sucks to not be able to create a self-sufficient group of objects just because someone that includes your group happens to also include a common object (in this case, common-obj-y). trace-obj-y should absolutely be able to note qemu-timer-common.o as an explicit dependency regardless of whether or not it happens to get linked in by something else in the common case.

Plus with talk of breaking up QEMU into shared objects I think we'd end up needing to have self-sufficient object groups anyway.

But, in the meantime, I broke something again so I put together a patch with Blue's suggestions that seems to do the trick fairly reasonably. I'll send it as a response for reference, though I'd really prefer the $(sort) approach.

configure approach works for me too.

Blue: Are you going to post the CONFIG_QEMU_TIMER patch?

Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]