On Tue, Sep 21, 2010 at 7:06 PM, Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 09/21/2010 01:32 PM, Blue Swirl wrote:
>>
>> On Mon, Sep 20, 2010 at 8:21 PM, Anthony Liguori<anth...@codemonkey.ws>
>> wrote:
>>
>>>
>>> On 09/20/2010 03:03 PM, Blue Swirl wrote:
>>>
>>>>
>>>> On Mon, Sep 20, 2010 at 6:41 PM, Blue Swirl<blauwir...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>>
>>>>> On Mon, Sep 20, 2010 at 6:26 PM, Anthony Liguori<anth...@codemonkey.ws>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> On 09/19/2010 11:16 AM, Blue Swirl wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 15, 2010 at 7:25 PM, Anthony
>>>>>>> Liguori<anth...@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.
0001-gnulib-let-compile-succeed-without-autostuff.patch
Description: application/mbox
0001-Add-gnulib-as-a-submodule.patch
Description: application/mbox
0002-mingw-Win2k-support-for-getaddrinfo-etc.patch
Description: application/mbox
