On Wed, Aug 10, 2011 at 9:14 AM, Stefan Hajnoczi <stefa...@linux.vnet.ibm.com> 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 <stefa...@gmail.com> wrote: >> > On Mon, Aug 8, 2011 at 10:01 AM, Aneesh Kumar K.V >> > <aneesh.ku...@linux.vnet.ibm.com> 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 >
