Re: gwlib/charset patch

Hi Nikos,

please try attached patch and let me know if it fixes warning on  
solaris.

Note: this patch just use already defined AM_ICONV macro to detect and  
declare iconv.
Due to the fact that this macro is defined in aclocal I added  
bootstrap.sh to use if you changed
configure.in. Usage of aclocal require renaming of aclocal.m4 to  
acinclude.m4.

Diff-Stat is here:
  .cvsignore      |    1 -
  acinclude.m4    |  193 ++++++++++
  aclocal.m4      | 1078 +++++++++++++++++++++++++++++++++++++++++++++ 
+---------
  bootstrap.sh    |    4 +
  configure       |  871 +++++++++++++++++++++++++++++++++++++++++----
  configure.in    |    5 +-
  gw-config.h.in  |    5 +-
  gwlib/charset.c |    6 +-
  8 files changed, 1916 insertions(+), 247 deletions(-)


Thanks,
Alex




Am 02.03.2009 um 09:28 schrieb Alexander Malysh:

> Hi Nikos,
>
> your patch doesn't break anything but generate the same warnings as  
> now for OSX, Solaris on Linux...
>
> Thanks,
> Alex
>
> Am 02.03.2009 um 08:46 schrieb Nikos Balkanas:
>
>> I agree that this is the right solution. However, i don't think it  
>> is worth it for a simple compiler warning. If we start claterring  
>> the code with too many preprocessor options for each system,  
>> quickly the code will become unreadable.
>>
>> My idea from the start was a simple straight thing. If it doesn't  
>> break other systems, implement it. Else forget it.
>>
>> Nikos
>> ----- Original Message ----- From: "Martin Conte Mac Donell" <[email protected] 
>> >
>> To: "Nikos Balkanas" <[email protected]>
>> Cc: <[email protected]>
>> Sent: Monday, March 02, 2009 5:59 AM
>> Subject: Re: gwlib/charset patch
>>
>>
>>> On Mon, Mar 2, 2009 at 1:11 AM, Nikos Balkanas  
>>> <[email protected]> wrote:
>>>> Martin,
>>>>
>>>> The only valid argument against the patch would be that (const  
>>>> char **)
>>>> causes warnings to other systems. If it does not, why not apply  
>>>> it to keep
>>>> everybody, including Solaris and OSX, happy?
>>>>
>>>> It is not an alternative to change libiconv sources or  
>>>> configuration,
>>>> especially if it doesn't make a difference for kannel.
>>>>
>>>> BR,
>>>> Nikos
>>>
>>> I'm not saying that we need to change libiconv. What i'm saying is
>>> that the "right way" to get over this warning is using a compiler
>>> conditional inside kannel. See my attached example.
>>>
>>> M.
>>
>>
>