Patchwork Win2k host problem with {get,free}{addr,name}info()

login
register
mail settings
Submitter Blue Swirl
Date Sept. 22, 2010, 5:36 p.m.
Message ID <AANLkTinXAphEVgBtesVtijDncVRGf0rw1ZfrcmXi083+@mail.gmail.com>
Download mbox | patch
Permalink /patch/65439/
State New
Headers show

Comments

Blue Swirl - Sept. 22, 2010, 5:36 p.m.
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:

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.

Patch

--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@ 
-Subproject commit cbd866a050ff5f9bcfbcab518ea0a9c449d8bee6
+Subproject commit 697a93c1d383f346fb1bead9ea47733ddda3ec7d