mingw-cross-env-list
[Top][All Lists]
Advanced

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

Re: [Mingw-cross-env-list] New package proposal: libircclient


From: Lothar May
Subject: Re: [Mingw-cross-env-list] New package proposal: libircclient
Date: Sun, 13 Mar 2011 21:09:55 +0100

Hi,

2011/3/13 Tony Theodore <address@hidden>:
> On 11 March 2011 12:59, Lothar May <address@hidden> wrote:
>> Hi,
>>
>> please find enclosed the proposed new package libircclient.
>> Since "make install" is broken, I install the required files by hand
>> (the same files as with libircclient 1.3 on Ubuntu/Debian are
>> installed, in the same structure, and they are sufficient for
>> developing).
>> The Makefile is also broken, a patch is included.
>
> That seems reasonable, though I wonder if it's also worth fixing the
> install target if you're patching Makefile.in anyway.
>
>> IPv6 support suffers
>> from a buffer overflow issue and works only partly, is therefore also
>> disabled.
>
> I'm not sure this is actually disabled, the only place config.h is
> used is in portable.c, and then only for non-win32 builds.
>
>> I can use the resulting lib for PokerTH, so in my case it works fine.
>>
>> I'm unsure about the define $(PKG)_UPDATE-part (was copied from
>> another package).
>
> This looks okay and returns the right result.
>
>> I'm also unsure about the "rcu" options to ar, they were also copied
>> because it did not work without them.
>
> You could get by with just "cr", but a better option is to pass
>
> --host='$(TARGET)'
>
> to configure. That way you can simply call make without CC/AR etc.
>
>> One question remains: The example program, if build in strict ANSI
>> mode, requires -DWIN32 because libircclient considers WIN32 instead of
>> _WIN32. Should I create a patch for libircclient and remove this
>> define?
>
> I'd say so, it's a fairly simple patch (you should also remove the U__*).


Thank you for your feedback. I'll improve things and send a new version.

Just wanted to post a patch for boost but Mark was faster :-) thanks!

Regards,
Lothar



reply via email to

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