Re: gcc BZ 112671

[Arsen Arsenović]

Hi Bruno,

Thanks for the response.

Bruno Haible <bruno@clisp.org> writes:

> [CCing bug-gettext, since AM_ICONV is documented as part of GNU gettext]
>
> Hi Arsen,
>
>> Would it be correct to set INCICONV and {LT,}LIBICONV when configuring
>> the tree instead of (or in addition to) modifying iconv.m4?
>
> The interface of iconv.m4 is defined here:
> https://www.gnu.org/software/gettext/manual/html_node/AM_005fICONV.html
> If you want to achieve compatible effects for an in-tree build, it is
>   - necessary, yes, to define LIBICONV and LIBICONV,
>   - but not effective to set the variable INCICONV. What the compatible
>     macro should do, is to add the -I option to CPPFLAGS.

I think I didn't explain the issue properly.

gettext-runtime also links libiconv, but gettext-runtime has configure
generated with an umodified iconv.m4.  Naturally, that unmodified
iconv.m4 has no idea about the sibling libiconv that can be built in the
toolchain tree.  I'm wondering about what the appropriate method of
informing gettext (and other iconv.m4 users) about where to find the
sibling libiconv.

If I can tell AM_ICONV where to find the sibling libiconv, I could
possibly leave an unmodified iconv.m4 in the toolchain tree.

> The reason why my autoconf macros add the -I option to CPPFLAGS, not
> merely to some variable such as INCICONV, is that generally it is more
> reliable to build an entire package with the same set of -I options.
> Adding a -I option to a compilation unit here, and another -I option
> to another compilation unit there, is fragile: In these directories
> there may be other .h files than iconv.h, say foo.h. In some compilation
> units '#include <foo.h>' would reference /usr/include/foo.h, in some
> other compilation units it would reference INCICONVDIR/foo.h.
> (This is, of course, what a build system does for its internal
> dependencies. But for external dependencies 'foo', such a thing can
> easily lead to arbitrarily complicated bugs.)

I see, that makes sense.  Thanks.

> Bruno

Have a lovely day!
-- 
Arsen Arsenović

signature.asc
Description: PGP signature