>> Looks good, thanks! Eli, do you have time to test it?
>
> If you commit the proceeds into the Groff repo, I could try testing
> tomorrow.
I've just committed Daiki-san's patch to the groff repository.
Thanks!
Werner
Eric Blake writes:
> m4_foreach causes the loop to be expanded at m4 time (a larger configure
> file). In this case, you could probably easily get by with a shell loop
> instead, for a smaller configure file (untested):
>
>for type in 'char **' 'const char **'; do
> AC_RUN_IFELS
On 10/21/2014 03:30 AM, Daiki Ueno wrote:
> Werner LEMBERG writes:
>
Given that the intention of the above test is to check if the iconv
function works properly, maybe a workaround would be to use the
fixed prototype of iconv (as attached)?
>>>
>>> Sorry, that was obviously wrong.
> Date: Tue, 21 Oct 2014 14:34:17 +0200 (CEST)
> Cc: e...@gnu.org, bug-gnulib@gnu.org
> From: Werner LEMBERG
>
>
> > The attached patch seems to work with both cases.
>
> Looks good, thanks! Eli, do you have time to test it?
If you commit the proceeds into the Groff repo, I could try testing
> The attached patch seems to work with both cases.
Looks good, thanks! Eli, do you have time to test it?
Werner
Werner LEMBERG writes:
>>> Given that the intention of the above test is to check if the iconv
>>> function works properly, maybe a workaround would be to use the
>>> fixed prototype of iconv (as attached)?
>>
>> Sorry, that was obviously wrong. The other idea is to suppress the
>> error with a
>> Given that the intention of the above test is to check if the iconv
>> function works properly, maybe a workaround would be to use the
>> fixed prototype of iconv (as attached)?
>
> Sorry, that was obviously wrong. The other idea is to suppress the
> error with a pragma, but I guess it would
