qemu-devel
[Top][All Lists]
Advanced

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

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


From: Blue Swirl
Subject: Re: [Qemu-devel] Win2k host problem with {get,free}{addr,name}info()
Date: Wed, 22 Sep 2010 17:36:53 +0000

On Tue, Sep 21, 2010 at 7:06 PM, Anthony Liguori <address@hidden> wrote:
> On 09/21/2010 01:32 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 20, 2010 at 8:21 PM, Anthony Liguori<address@hidden>
>>  wrote:
>>
>>>
>>> On 09/20/2010 03:03 PM, Blue Swirl wrote:
>>>
>>>>
>>>> On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl<address@hidden>
>>>>  wrote:
>>>>
>>>>
>>>>>
>>>>> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori<address@hidden>
>>>>>  wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony
>>>>>>> Liguori<address@hidden>
>>>>>>>  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: 0001-gnulib-let-compile-succeed-without-autostuff.patch
Description: application/mbox

Attachment: 0001-Add-gnulib-as-a-submodule.patch
Description: application/mbox

Attachment: 0002-mingw-Win2k-support-for-getaddrinfo-etc.patch
Description: application/mbox


reply via email to

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