bug-gnulib
[Top][All Lists]
Advanced

[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.



reply via email to

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