[Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

Hi,

I tried to test QEMU on Win2k, but there are run time errors because
of missing {get,free}{addr,name}info() functions. After adding dummy
defines in place, there are no more errors.

I found a similar case, where a compatibility patch was proposed:
http://trac.filezilla-project.org/ticket/1532

The patch is a bit heavy, consisting of run time detection of Win2k
and full replacements for the functions. Are there any alternative
solutions? I'm by no means a Windows expert.

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Anthony Liguori]

On 09/15/2010 02:11 PM, Blue Swirl wrote:
> Hi,
>
> I tried to test QEMU on Win2k, but there are run time errors because
> of missing {get,free}{addr,name}info() functions. After adding dummy
> defines in place, there are no more errors.
>
> I found a similar case, where a compatibility patch was proposed:
> http://trac.filezilla-project.org/ticket/1532
>
> The patch is a bit heavy, consisting of run time detection of Win2k
> and full replacements for the functions. Are there any alternative
> solutions? I'm by no means a Windows expert.
>    

Win2k is EOL so I don't think it's useful for us to support it as a 
host.  So any type of patch is just going to add additional complexity 
for very little real gain.

Regards,

Anthony Liguori

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>
>> Hi,
>>
>> I tried to test QEMU on Win2k, but there are run time errors because
>> of missing {get,free}{addr,name}info() functions. After adding dummy
>> defines in place, there are no more errors.
>>
>> I found a similar case, where a compatibility patch was proposed:
>> http://trac.filezilla-project.org/ticket/1532
>>
>> The patch is a bit heavy, consisting of run time detection of Win2k
>> and full replacements for the functions. Are there any alternative
>> solutions? I'm by no means a Windows expert.
>>
>
> Win2k is EOL so I don't think it's useful for us to support it as a host.
>  So any type of patch is just going to add additional complexity for very
> little real gain.

I made a compatibility patch based on the FileZilla patch. The impact
is very low, outside of the new files added, only Makefiles are
changed.

With the patch I was able to run QEMU with network connectivity on
Win2k. Also the tools work, they also seem to depend on getaddrinfo &
co.

 Makefile          |    6
 Makefile.objs     |    3
 Makefile.target   |    1
 net/getaddrinfo.c |  413 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 net/getaddrinfo.h |  121 +++++++++++++++
 net/inet_ntop.c   |  237 ++++++++++++++++++++++++++++++
 net/inet_ntop.h   |   47 ++++++
 7 files changed, 825 insertions(+), 3 deletions(-)

[-- Attachment #2: 0001-mingw-Win2k-support-for-getaddrinfo-etc.patch --]
[-- Type: application/mbox, Size: 28805 bytes --]

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Joe Ross]

On Wednesday, September 15, 2010, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Win2k is EOL so I don't think it's useful for us to support it as a host.  So any type of patch is just going to add additional complexity for very little real gain.
>

While Win2k probably isn't likely to be used in a virtualized server
anymore, it's still useful for running old software.

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

On Mon, Sep 20, 2010 at 4:16 AM, Joe Ross <joe.ross@gmail.com> wrote:
> On Wednesday, September 15, 2010, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Win2k is EOL so I don't think it's useful for us to support it as a host.  So any type of patch is just going to add additional complexity for very little real gain.
>>
>
> While Win2k probably isn't likely to be used in a virtualized server
> anymore, it's still useful for running old software.

That's a different problem, Win2k as a guest.

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Anthony Liguori]

On 09/19/2010 11:16 AM, Blue Swirl wrote:
> On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>      
>>> Hi,
>>>
>>> I tried to test QEMU on Win2k, but there are run time errors because
>>> of missing {get,free}{addr,name}info() functions. After adding dummy
>>> defines in place, there are no more errors.
>>>
>>> I found a similar case, where a compatibility patch was proposed:
>>> http://trac.filezilla-project.org/ticket/1532
>>>
>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>> and full replacements for the functions. Are there any alternative
>>> solutions? I'm by no means a Windows expert.
>>>
>>>        
>> Win2k is EOL so I don't think it's useful for us to support it as a host.
>>   So any type of patch is just going to add additional complexity for very
>> little real gain.
>>      
> I made a compatibility patch based on the FileZilla patch. The impact
> is very low, outside of the new files added, only Makefiles are
> changed.
>    

Does gnulib have a similar replacement function?

The nice thing about gnulib is that in the long term, we could 
potentially use gnulib for compatibility and make sure to get updated code.

Regards,

Anthony Liguori

> With the patch I was able to run QEMU with network connectivity on
> Win2k. Also the tools work, they also seem to depend on getaddrinfo&
> co.
>
>   Makefile          |    6
>   Makefile.objs     |    3
>   Makefile.target   |    1
>   net/getaddrinfo.c |  413 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   net/getaddrinfo.h |  121 +++++++++++++++
>   net/inet_ntop.c   |  237 ++++++++++++++++++++++++++++++
>   net/inet_ntop.h   |   47 ++++++
>   7 files changed, 825 insertions(+), 3 deletions(-)
>    

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>
>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I tried to test QEMU on Win2k, but there are run time errors because
>>>> of missing {get,free}{addr,name}info() functions. After adding dummy
>>>> defines in place, there are no more errors.
>>>>
>>>> I found a similar case, where a compatibility patch was proposed:
>>>> http://trac.filezilla-project.org/ticket/1532
>>>>
>>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>>> and full replacements for the functions. Are there any alternative
>>>> solutions? I'm by no means a Windows expert.
>>>>
>>>>
>>>
>>> Win2k is EOL so I don't think it's useful for us to support it as a host.
>>>  So any type of patch is just going to add additional complexity for very
>>> little real gain.
>>>
>>
>> I made a compatibility patch based on the FileZilla patch. The impact
>> is very low, outside of the new files added, only Makefiles are
>> changed.
>>
>
> Does gnulib have a similar replacement function?

Very similar, in fact that must be the source.

> The nice thing about gnulib is that in the long term, we could potentially
> use gnulib for compatibility and make sure to get updated code.

One problem is that the current versions use GPLv3.

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>
>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>  wrote:
>>>
>>>>
>>>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I tried to test QEMU on Win2k, but there are run time errors because
>>>>> of missing {get,free}{addr,name}info() functions. After adding dummy
>>>>> defines in place, there are no more errors.
>>>>>
>>>>> I found a similar case, where a compatibility patch was proposed:
>>>>> http://trac.filezilla-project.org/ticket/1532
>>>>>
>>>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>>>> and full replacements for the functions. Are there any alternative
>>>>> solutions? I'm by no means a Windows expert.
>>>>>
>>>>>
>>>>
>>>> Win2k is EOL so I don't think it's useful for us to support it as a host.
>>>>  So any type of patch is just going to add additional complexity for very
>>>> little real gain.
>>>>
>>>
>>> I made a compatibility patch based on the FileZilla patch. The impact
>>> is very low, outside of the new files added, only Makefiles are
>>> changed.
>>>
>>
>> Does gnulib have a similar replacement function?
>
> Very similar, in fact that must be the source.
>
>> The nice thing about gnulib is that in the long term, we could potentially
>> use gnulib for compatibility and make sure to get updated code.
>
> One problem is that the current versions use GPLv3.

Sorry, I made too hasty conclusions based on a few files.
getaddrinfo.c and inet_ntop.c are both GPLv2+.

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/getaddrinfo.c;h=76dc19e6c4f945a1fa725abeb2d5a6174046b773;hb=HEAD

http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/inet_ntop.c;h=2251aaa05663d1137a2f14a947142438791b488a;hb=HEAD

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Anthony Liguori]

On 09/20/2010 03:03 PM, Blue Swirl wrote:
> On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl<blauwirbel@gmail.com>  wrote:
>    
>> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>>      
>>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>        
>>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>   wrote:
>>>>
>>>>          
>>>>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>>>>
>>>>>            
>>>>>> Hi,
>>>>>>
>>>>>> I tried to test QEMU on Win2k, but there are run time errors because
>>>>>> of missing {get,free}{addr,name}info() functions. After adding dummy
>>>>>> defines in place, there are no more errors.
>>>>>>
>>>>>> I found a similar case, where a compatibility patch was proposed:
>>>>>> http://trac.filezilla-project.org/ticket/1532
>>>>>>
>>>>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>>>>> and full replacements for the functions. Are there any alternative
>>>>>> solutions? I'm by no means a Windows expert.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Win2k is EOL so I don't think it's useful for us to support it as a host.
>>>>>   So any type of patch is just going to add additional complexity for very
>>>>> little real gain.
>>>>>
>>>>>            
>>>> I made a compatibility patch based on the FileZilla patch. The impact
>>>> is very low, outside of the new files added, only Makefiles are
>>>> changed.
>>>>
>>>>          
>>> Does gnulib have a similar replacement function?
>>>        
>> Very similar, in fact that must be the source.
>>
>>      
>>> The nice thing about gnulib is that in the long term, we could potentially
>>> use gnulib for compatibility and make sure to get updated code.
>>>        
>> One problem is that the current versions use GPLv3.
>>      
> Sorry, I made too hasty conclusions based on a few files.
> getaddrinfo.c and inet_ntop.c are both GPLv2+.
>    

Perfect, that works out very well then.

Regards,

Anthony Liguori

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Paolo Bonzini]

>>> Does gnulib have a similar replacement function?
>>
>> Very similar, in fact that must be the source.
>>
>>> The nice thing about gnulib is that in the long term, we could potentially
>>> use gnulib for compatibility and make sure to get updated code.
>>
>> One problem is that the current versions use GPLv3.
>
> Sorry, I made too hasty conclusions based on a few files.
> getaddrinfo.c and inet_ntop.c are both GPLv2+.

gnulib has a mix of various licenses.  People are usually not too picky 
about relicensing GPLv3 stuff to GPLv2+ and LGPLv3 stuff to either 
LGPLv2+, or dual GPLv2/LGPLv3.

However, using gnulib may require autoconfiscation of qemu.

Paolo

Re: [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Bastien ROUCARIES]

On Tue, Sep 21, 2010 at 10:09 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> Does gnulib have a similar replacement function?
>>>
>>> Very similar, in fact that must be the source.
>>>
>>>> The nice thing about gnulib is that in the long term, we could
>>>> potentially
>>>> use gnulib for compatibility and make sure to get updated code.
>>>
>>> One problem is that the current versions use GPLv3.
>>
>> Sorry, I made too hasty conclusions based on a few files.
>> getaddrinfo.c and inet_ntop.c are both GPLv2+.
>
> gnulib has a mix of various licenses.  People are usually not too picky
> about relicensing GPLv3 stuff to GPLv2+ and LGPLv3 stuff to either LGPLv2+,
> or dual GPLv2/LGPLv3.
>
> However, using gnulib may require autoconfiscation of qemu.

Not sure you could put the autoconf stuff is a well isolated directory
and use the libposix trick

I use gnulib with cmake in this way

Bastien

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Mon, Sep 20, 2010 at 8:21 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 09/20/2010 03:03 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl<blauwirbel@gmail.com>  wrote:
>>
>>>
>>> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>  wrote:
>>>
>>>>
>>>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>>
>>>>>
>>>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>>  wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I tried to test QEMU on Win2k, but there are run time errors because
>>>>>>> of missing {get,free}{addr,name}info() functions. After adding dummy
>>>>>>> defines in place, there are no more errors.
>>>>>>>
>>>>>>> I found a similar case, where a compatibility patch was proposed:
>>>>>>> http://trac.filezilla-project.org/ticket/1532
>>>>>>>
>>>>>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>>>>>> and full replacements for the functions. Are there any alternative
>>>>>>> solutions? I'm by no means a Windows expert.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Win2k is EOL so I don't think it's useful for us to support it as a
>>>>>> host.
>>>>>>  So any type of patch is just going to add additional complexity for
>>>>>> very
>>>>>> little real gain.
>>>>>>
>>>>>>
>>>>>
>>>>> I made a compatibility patch based on the FileZilla patch. The impact
>>>>> is very low, outside of the new files added, only Makefiles are
>>>>> changed.
>>>>>
>>>>>
>>>>
>>>> Does gnulib have a similar replacement function?
>>>>
>>>
>>> Very similar, in fact that must be the source.
>>>
>>>
>>>>
>>>> The nice thing about gnulib is that in the long term, we could
>>>> potentially
>>>> use gnulib for compatibility and make sure to get updated code.
>>>>
>>>
>>> One problem is that the current versions use GPLv3.
>>>
>>
>> Sorry, I made too hasty conclusions based on a few files.
>> getaddrinfo.c and inet_ntop.c are both GPLv2+.
>>
>
> Perfect, that works out very well then.

Sort of, gnulib needs some configuration before use. I made some hacks
to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
but it's getting ugly.

Actually, there's no 'configure' in gnulib HEAD even though
docs/INSTALL mentions that. Strange.

Is it possible to apply local patches to a submodule tree?

[-- Attachment #2: 0001-Add-gnulib-as-a-submodule.patch --]
[-- Type: application/mbox, Size: 904 bytes --]

[-- Attachment #3: 0002-mingw-Win2k-support-for-getaddrinfo-etc.patch --]
[-- Type: application/mbox, Size: 3663 bytes --]

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Anthony Liguori]

On 09/21/2010 01:32 PM, Blue Swirl wrote:
> On Mon, Sep 20, 2010 at 8:21 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 09/20/2010 03:03 PM, Blue Swirl wrote:
>>      
>>> On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl<blauwirbel@gmail.com>    wrote:
>>>
>>>        
>>>> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>   wrote:
>>>>
>>>>          
>>>>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>>>
>>>>>            
>>>>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>>>   wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I tried to test QEMU on Win2k, but there are run time errors because
>>>>>>>> of missing {get,free}{addr,name}info() functions. After adding dummy
>>>>>>>> defines in place, there are no more errors.
>>>>>>>>
>>>>>>>> I found a similar case, where a compatibility patch was proposed:
>>>>>>>> http://trac.filezilla-project.org/ticket/1532
>>>>>>>>
>>>>>>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>>>>>>> and full replacements for the functions. Are there any alternative
>>>>>>>> solutions? I'm by no means a Windows expert.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                  
>>>>>>> Win2k is EOL so I don't think it's useful for us to support it as a
>>>>>>> host.
>>>>>>>   So any type of patch is just going to add additional complexity for
>>>>>>> very
>>>>>>> little real gain.
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> I made a compatibility patch based on the FileZilla patch. The impact
>>>>>> is very low, outside of the new files added, only Makefiles are
>>>>>> changed.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Does gnulib have a similar replacement function?
>>>>>
>>>>>            
>>>> Very similar, in fact that must be the source.
>>>>
>>>>
>>>>          
>>>>> The nice thing about gnulib is that in the long term, we could
>>>>> potentially
>>>>> use gnulib for compatibility and make sure to get updated code.
>>>>>
>>>>>            
>>>> One problem is that the current versions use GPLv3.
>>>>
>>>>          
>>> Sorry, I made too hasty conclusions based on a few files.
>>> getaddrinfo.c and inet_ntop.c are both GPLv2+.
>>>
>>>        
>> Perfect, that works out very well then.
>>      
> Sort of, gnulib needs some configuration before use. I made some hacks
> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
> but it's getting ugly.
>
> Actually, there's no 'configure' in gnulib HEAD even though
> docs/INSTALL mentions that. Strange.
>
> Is it possible to apply local patches to a submodule tree?
>    

You mean in git?  If you fork the submodule, you can carry patches and 
then merge back with the original tree.

Regards,

Anthony Liguori

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Paolo Bonzini]

On 09/21/2010 08:32 PM, Blue Swirl wrote:
> Sort of, gnulib needs some configuration before use. I made some hacks
> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
> but it's getting ugly.
>
> Actually, there's no 'configure' in gnulib HEAD even though
> docs/INSTALL mentions that. Strange.

gnulib's docs/INSTALL is a template for packages using autotools, it's 
not for gnulib itself.

> Is it possible to apply local patches to a submodule tree?

It is not needed; to explain this, you need to go one step back.

gnulib's submodule is never built directly.  It only lives in the build 
tree so that it can be consulted by gnulib-tool, but it doesn't even 
make it to the release tarballs.  Instead, gnulib-tool should be invoked 
after checking out superproject.git, and copies selected gnulib files 
into superproject's checkout (these files are .gitignore'd).

Now, gnulib-tool also take care of applying patches to the files it 
copies, so the correct question is "is it possible to apply local 
patches to gnulib files" and the answer is "yes".

That said, as much as I am a fan of autotools, I think using gnulib 
within qemu would be a big mess.

Paolo

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Paolo Bonzini]

On 09/21/2010 08:32 PM, Blue Swirl wrote:
> Sort of, gnulib needs some configuration before use. I made some hacks
> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
> but it's getting ugly.
>
> Actually, there's no 'configure' in gnulib HEAD even though
> docs/INSTALL mentions that. Strange.

gnulib's docs/INSTALL is a template for packages using autotools, it's 
not for gnulib itself.

> Is it possible to apply local patches to a submodule tree?

It is not needed; to explain this, you need to go one step back.

gnulib's submodule is never built directly.  It only lives in the build 
tree so that it can be consulted by gnulib-tool, but it doesn't even 
make it to the release tarballs.  Instead, gnulib-tool should be invoked 
after checking out superproject.git, and copies selected gnulib files 
into superproject's checkout (these files are .gitignore'd).

Now, gnulib-tool also take care of applying patches to the files it 
copies, so the correct question is "is it possible to apply local 
patches to gnulib files" and the answer is "yes".

That said, as much as I am a fan of autotools, I think using gnulib 
within qemu would be a big mess.

Paolo

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Anthony Liguori]

On 09/22/2010 08:40 AM, Paolo Bonzini wrote:
> On 09/21/2010 08:32 PM, Blue Swirl wrote:
>> Sort of, gnulib needs some configuration before use. I made some hacks
>> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
>> but it's getting ugly.
>>
>> Actually, there's no 'configure' in gnulib HEAD even though
>> docs/INSTALL mentions that. Strange.
>
> gnulib's docs/INSTALL is a template for packages using autotools, it's 
> not for gnulib itself.
>
>> Is it possible to apply local patches to a submodule tree?
>
> It is not needed; to explain this, you need to go one step back.
>
> gnulib's submodule is never built directly.  It only lives in the 
> build tree so that it can be consulted by gnulib-tool, but it doesn't 
> even make it to the release tarballs.  Instead, gnulib-tool should be 
> invoked after checking out superproject.git, and copies selected 
> gnulib files into superproject's checkout (these files are .gitignore'd).
>
> Now, gnulib-tool also take care of applying patches to the files it 
> copies, so the correct question is "is it possible to apply local 
> patches to gnulib files" and the answer is "yes".
>
> That said, as much as I am a fan of autotools, I think using gnulib 
> within qemu would be a big mess.

If someone was willing to put in the effort, I'd be very supportive of 
moving QEMU to autotools.

Regards,

Anthony Liguori

> Paolo

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Paolo Bonzini]

On 09/22/2010 03:42 PM, Anthony Liguori wrote:
> If someone was willing to put in the effort, I'd be very supportive of
> moving QEMU to autotools.

For 0.14 it would be a nice start to convert the command line to 
something more autoconfy (e.g. MAKE=<make> instead of --make=<make>).

Paolo

Re: [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[malc]

On Wed, 22 Sep 2010, Anthony Liguori wrote:

> On 09/22/2010 08:40 AM, Paolo Bonzini wrote:
> > On 09/21/2010 08:32 PM, Blue Swirl wrote:
> > > Sort of, gnulib needs some configuration before use. I made some hacks
> > > to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
> > > but it's getting ugly.
> > > 
> > > Actually, there's no 'configure' in gnulib HEAD even though
> > > docs/INSTALL mentions that. Strange.
> > 
> > gnulib's docs/INSTALL is a template for packages using autotools, it's not
> > for gnulib itself.
> > 
> > > Is it possible to apply local patches to a submodule tree?
> > 
> > It is not needed; to explain this, you need to go one step back.
> > 
> > gnulib's submodule is never built directly.  It only lives in the build tree
> > so that it can be consulted by gnulib-tool, but it doesn't even make it to
> > the release tarballs.  Instead, gnulib-tool should be invoked after checking
> > out superproject.git, and copies selected gnulib files into superproject's
> > checkout (these files are .gitignore'd).
> > 
> > Now, gnulib-tool also take care of applying patches to the files it copies,
> > so the correct question is "is it possible to apply local patches to gnulib
> > files" and the answer is "yes".
> > 
> > That said, as much as I am a fan of autotools, I think using gnulib within
> > qemu would be a big mess.
> 
> If someone was willing to put in the effort, I'd be very supportive of moving
> QEMU to autotools.

And i'll be against it.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Paolo Bonzini]

On 09/22/2010 05:27 PM, malc wrote:
> On Wed, 22 Sep 2010, Anthony Liguori wrote:
>> If someone was willing to put in the effort, I'd be very supportive of moving
>> QEMU to autotools.
>
> And i'll be against it.

This somehow doesn't surprise me.

Anyway, what do you think about the idea of making the command-line of 
QEMU configure more autoconfy?

Paolo

Re: [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[malc]

On Wed, 22 Sep 2010, Paolo Bonzini wrote:

> On 09/22/2010 05:27 PM, malc wrote:
> > On Wed, 22 Sep 2010, Anthony Liguori wrote:
> > > If someone was willing to put in the effort, I'd be very supportive of
> > > moving
> > > QEMU to autotools.
> > 
> > And i'll be against it.
> 
> This somehow doesn't surprise me.
> 
> Anyway, what do you think about the idea of making the command-line of QEMU
> configure more autoconfy?

Indifferent.

-- 
mailto:av1474@comtv.ru

Re: [Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Anthony Liguori]

On 09/22/2010 10:27 AM, malc wrote:
>> If someone was willing to put in the effort, I'd be very supportive of moving
>> QEMU to autotools.
>>      
> And i'll be against it.
>    

I'd prefer to wait to have this flame war until after someone expresses 
realistic interesting in such an effort.

Suffice to say, there's a lot of convincing that would be required to 
integrate something like autotools.

Regards,

Anthony Liguori

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Blue Swirl]

On Wed, Sep 22, 2010 at 1:40 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 09/21/2010 08:32 PM, Blue Swirl wrote:
>>
>> Sort of, gnulib needs some configuration before use. I made some hacks
>> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
>> but it's getting ugly.
>>
>> Actually, there's no 'configure' in gnulib HEAD even though
>> docs/INSTALL mentions that. Strange.
>
> gnulib's docs/INSTALL is a template for packages using autotools, it's not
> for gnulib itself.
>
>> Is it possible to apply local patches to a submodule tree?
>
> It is not needed; to explain this, you need to go one step back.
>
> gnulib's submodule is never built directly.  It only lives in the build tree
> so that it can be consulted by gnulib-tool, but it doesn't even make it to
> the release tarballs.  Instead, gnulib-tool should be invoked after checking
> out superproject.git, and copies selected gnulib files into superproject's
> checkout (these files are .gitignore'd).

gnulib-tool wants to patch configure.ac. After adding an empty one and
running "gnulib-tool --import getaddrinfo inet_ntop", it still remains
empty. Not very clever. There are a lot of .c files, some .h files and
also a lot of .m4 files.

I think we want to avoid this path.

Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 3515 bytes --]

On Tue, Sep 21, 2010 at 7:06 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
> On 09/21/2010 01:32 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 20, 2010 at 8:21 PM, Anthony Liguori<anthony@codemonkey.ws>
>>  wrote:
>>
>>>
>>> On 09/20/2010 03:03 PM, Blue Swirl wrote:
>>>
>>>>
>>>> On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl<blauwirbel@gmail.com>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori<anthony@codemonkey.ws>
>>>>>  wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony
>>>>>>> Liguori<anthony@codemonkey.ws>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> On 09/15/2010 02:11 PM, Blue Swirl wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I tried to test QEMU on Win2k, but there are run time errors
>>>>>>>>> because
>>>>>>>>> of missing {get,free}{addr,name}info() functions. After adding
>>>>>>>>> dummy
>>>>>>>>> defines in place, there are no more errors.
>>>>>>>>>
>>>>>>>>> I found a similar case, where a compatibility patch was proposed:
>>>>>>>>> http://trac.filezilla-project.org/ticket/1532
>>>>>>>>>
>>>>>>>>> The patch is a bit heavy, consisting of run time detection of Win2k
>>>>>>>>> and full replacements for the functions. Are there any alternative
>>>>>>>>> solutions? I'm by no means a Windows expert.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Win2k is EOL so I don't think it's useful for us to support it as a
>>>>>>>> host.
>>>>>>>>  So any type of patch is just going to add additional complexity for
>>>>>>>> very
>>>>>>>> little real gain.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I made a compatibility patch based on the FileZilla patch. The impact
>>>>>>> is very low, outside of the new files added, only Makefiles are
>>>>>>> changed.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Does gnulib have a similar replacement function?
>>>>>>
>>>>>>
>>>>>
>>>>> Very similar, in fact that must be the source.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> The nice thing about gnulib is that in the long term, we could
>>>>>> potentially
>>>>>> use gnulib for compatibility and make sure to get updated code.
>>>>>>
>>>>>>
>>>>>
>>>>> One problem is that the current versions use GPLv3.
>>>>>
>>>>>
>>>>
>>>> Sorry, I made too hasty conclusions based on a few files.
>>>> getaddrinfo.c and inet_ntop.c are both GPLv2+.
>>>>
>>>>
>>>
>>> Perfect, that works out very well then.
>>>
>>
>> Sort of, gnulib needs some configuration before use. I made some hacks
>> to avoid that and also suppressed warnings by overriding QEMU_CFLAGS,
>> but it's getting ugly.
>>
>> Actually, there's no 'configure' in gnulib HEAD even though
>> docs/INSTALL mentions that. Strange.
>>
>> Is it possible to apply local patches to a submodule tree?
>>
>
> You mean in git?  If you fork the submodule, you can carry patches and then
> merge back with the original tree.

The commits in the submodule are not shown, in the superproject tree
there is only:
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit cbd866a050ff5f9bcfbcab518ea0a9c449d8bee6
+Subproject commit 697a93c1d383f346fb1bead9ea47733ddda3ec7d

Otherwise this approach seems to work.

Should QEMU configure do something to get the subproject tree
populated? If needed, maybe we can add a new flag to configure, for
example --enable-gnulib.

[-- Attachment #2: 0001-gnulib-let-compile-succeed-without-autostuff.patch --]
[-- Type: application/mbox, Size: 3793 bytes --]

[-- Attachment #3: 0001-Add-gnulib-as-a-submodule.patch --]
[-- Type: application/mbox, Size: 904 bytes --]

[-- Attachment #4: 0002-mingw-Win2k-support-for-getaddrinfo-etc.patch --]
[-- Type: application/mbox, Size: 3355 bytes --]

[Qemu-devel] Re: Win2k host problem with {get, free}{addr, name}info()

[Paolo Bonzini]

On 09/22/2010 07:16 PM, Blue Swirl wrote:
>> gnulib's submodule is never built directly.  It only lives in the build tree
>> so that it can be consulted by gnulib-tool, but it doesn't even make it to
>> the release tarballs.  Instead, gnulib-tool should be invoked after checking
>> out superproject.git, and copies selected gnulib files into superproject's
>> checkout (these files are .gitignore'd).
>
> gnulib-tool wants to patch configure.ac. After adding an empty one and
> running "gnulib-tool --import getaddrinfo inet_ntop", it still remains
> empty. Not very clever. There are a lot of .c files, some .h files and
> also a lot of .m4 files.

I agree that your posted patch is the best way---also considering that 
the path to autotools (autoconf, at least) is laden with deprecation 
periods and flamewars.

Paolo