[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libiconv detection failure
From: |
Eli Zaretskii |
Subject: |
Re: libiconv detection failure |
Date: |
Wed, 22 Oct 2014 17:49:22 +0300 |
> From: Daiki Ueno <address@hidden>
> Cc: Werner LEMBERG <address@hidden>, address@hidden, address@hidden
> Date: Wed, 22 Oct 2014 12:58:29 +0900
>
> > 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_IFELSE([AC_LANG_PROGRAM([[
> > ...
> > typedef $type gl_iconv_buf_t;
>
> Yes, thanks for the suggestion. I've ended up with the attached patch,
> with some more cleanup.
>
> Eli: I think it is sufficient to compare the configure output of
> before/after the change, using test packages:
> Before: http://du-a.org/~ueno/junk/test-iconv-0.tar.gz
> After: http://du-a.org/~ueno/junk/test-iconv-1.tar.gz
Thanks, I did that, and this solution doesn't work, in the sense that,
if a C++ compiler is used to compile the test program (which is what
happens when Groff is configured), both tests in test-iconv-1 fail.
I think we need to step back a notch, because it seems to me the
problem is not understood correctly.
The prototype of 'iconv' in GNU libiconv's iconv.h is this:
size_t iconv (iconv_t cd, const char** inbuf, size_t *inbytesleft,
char** outbuf, size_t *outbytesleft);
The 'const' qualifier of the 2nd argument is decided at libiconv
configuration time, and may be absent. But the 4th argument is
_never_ given a 'const' qualifier. Since the modified test program
type-casts both the 2nd and the 4th argument, both variants fail: one
because the 2nd argument is type-cast to incorrect type, the other
because the 4th argument is type-cast.
Next, it looks to me that the test program in iconv.m4 is
inappropriate for a C++ compiler, because (AFAIK) C++ does not allow
type-casting of the kind that the original test program (before your
changes) did to the 2nd argument. (With a C compiler, you get a
warning, which the configure script ignores.)
Therefore, I suggest to leave alone the type-casting, and instead
change the type of the input[] array (and only of the input array)
when it is declared and defined, using the gl_iconv_buf_t value.
- Re: libiconv detection failure, (continued)
- Re: libiconv detection failure, Daiki Ueno, 2014/10/21
- Re: libiconv detection failure, Daiki Ueno, 2014/10/21
- Re: libiconv detection failure, Werner LEMBERG, 2014/10/21
- Re: libiconv detection failure, Daiki Ueno, 2014/10/21
- Re: libiconv detection failure, Werner LEMBERG, 2014/10/21
- Re: libiconv detection failure, Eli Zaretskii, 2014/10/21
- Re: libiconv detection failure, Werner LEMBERG, 2014/10/22
- Re: libiconv detection failure, Eli Zaretskii, 2014/10/22
- Re: libiconv detection failure, Eric Blake, 2014/10/21
- Re: libiconv detection failure, Daiki Ueno, 2014/10/21
- Re: libiconv detection failure,
Eli Zaretskii <=
- Re: libiconv detection failure, Daiki Ueno, 2014/10/23
- Re: libiconv detection failure, Eli Zaretskii, 2014/10/23
- Re: libiconv detection failure, Daiki Ueno, 2014/10/23
- Re: libiconv detection failure, Werner LEMBERG, 2014/10/23