Re: [Qemu-devel] build failure with coroutine-gthread

[Blue Swirl]

On Wed, Aug 10, 2011 at 9:14 AM, Stefan Hajnoczi
<address@hidden> wrote:
> On Tue, Aug 09, 2011 at 05:28:17PM +0000, Blue Swirl wrote:
>> On Mon, Aug 8, 2011 at 9:29 AM, Stefan Hajnoczi <address@hidden> wrote:
>> > On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V
>> > <address@hidden> wrote:
>> >>
>> >>
>> >>  LINK  qemu-ga
>> >> coroutine-gthread.o: In function `coroutine_init':
>> >> /home/opensource/sources/qemu/qemu-upstream/coroutine-gthread.c:39: 
>> >> undefined reference to `g_thread_init'
>> >> collect2: ld returned 1 exit status
>> >>
>> >> The below patch fix the failure.  I also added the patch in the VirtFS
>> >> pull request.
>> >
>> > It appears coroutine-core v7 was merged instead of v8.  The
>> > differences are minor:
>> >  * Bisectability: introduce gthread implementation before ucontext/fibers
>> >  * Depend on gthread, not just glib, for multithreaded programming
>> >
>> > Here is the patchwork link to the gthread dependency patch in case a
>> > committer wants to merge it immediately:
>> > http://patchwork.ozlabs.org/patch/106810/
>>
>> Coroutines only need gthreads when both ucontext and win32 versions
>> are unavailable. This is handled better by my patch:
>> http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg00998.html
>
> Instead of adding more conditions around glib we should unconditionally
> depend on it.  Dependencies always have an associated cost but I intend
> to use glib instead of reimplementing platform abstractions and common
> data structures.

I also thought glib dependency was going to be unconditional, but then
this conditional dependency was introduced. Either make it
unconditional or fix the condition.

> The cost of maintaining non-emulation/non-virtualization code isn't
> worth avoiding the dependency.  In fact I wish glib provided coroutines
> so we didn't need to implement them ourselves.
>
> Stefan
>