qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] Fix compilation of nbd on Windows


From: Johannes Schindelin
Subject: Re: [Qemu-devel] [PATCH v2] Fix compilation of nbd on Windows
Date: Sun, 3 Aug 2008 23:30:37 +0200 (CEST)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

Hi Anthony,

On Sun, 3 Aug 2008, Anthony Liguori wrote:

> Johannes Schindelin wrote:
>
> > On Sun, 3 Aug 2008, Anthony Liguori wrote:
> >
> > > Johannes Schindelin wrote:
> > >     
> > > > Indeed, it seems that inet_aton() is defined in slirp/misc.c.  So 
> > > > qemu_socket.h is not even the right place for the definition, but 
> > > > better than nothing.
> > >
> > > Ugh, I wonder what happens when you do --disable-slirp :-( Do you 
> > > want to work up a patch to sanitize all of this or should I?
> >
> > You mean to keep my static implementation, but put it in an #ifndef 
> > CONFIG_SLIRP, with the #else branch declaring the function?
> >
> > Sure, I can do it, just tell me if that is what you meant.
> 
> It's all pretty messy right now.  I tried to wrap your static 
> implementation in a #ifdef QEMU_IMG but then nbd.o gets linked into both 
> qemu and qemu-nbd which makes things a pain.  I actually ended up just 
> removing the declaration in vl.c and that seemed to work.

Yes, I just realized that it gets messy.

> Whatever you can do that will make it so we're only using a single 
> implementation of inet_aton() will make me happy.

Well, we cannot cleanly include qemu_socket.h from slirp, can we?  And we 
cannot link qemu_common.a to qemu-img because of the missing 
implementations for *_input().

So I think that unfortunately, we have no clean way to have a single 
implementation, short of having a separate "inet_aton.h" in slirp/ with a 
static implementation...

The whole issue only arises because Win32 misses inet_aton(), sigh.

Ciao,
Dscho





reply via email to

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