Re: java/4972: undefined reference to `libiconv', AM_ICONV

[Bruno Haible <haible at ilog dot fr>]

Tom Tromey writes:
> We're using your `AM_ICONV' macro in gcc so that users without iconv
> can use your libiconv library.  The version we are using is marked
> "#serial AM2".
> 
> A user reported a link problem which we tracked down to a problem with
> this macro.  In this situation the user is using Solaris but also has
> libiconv installed in /usr/local.  configure detects the libiconv
> <iconv.h>, but AM_ICONV seems to decide that no -liconv is required,
> as it sees the iconv() in the C library.
> 
> The workaround is for the user to configure using
> --with-libiconv-prefix.  I think it would be more helpful if AM_ICONV
> detected this situation automatically and compensated somehow.
> 
> If you want to see the original bug report, it is PR 4972 in the gcc
> Gnats database.

Hi,

Together with the log file from the gcc-bugs mailing list (I have no
access to the Gnats database) I get the following picture.

I can see a succeeding command in stage1

gcc  -DIN_GCC    -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
	c-parse.o c-lang.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o c-semantics.o libcpp.a  main.o libbackend.a obstack.o ./intl/libintl.a      ../libiberty/libiberty.a

and a failing command in stage2

stage1/xgcc -Bstage1/ -B/usr/lsd/SunOS.5.8/sparc-sun-solaris2.8/bin/  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
	c-parse.o c-lang.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o c-semantics.o libcpp.a  main.o libbackend.a obstack.o ./intl/libintl.a      ../libiberty/libiberty.a
./intl/libintl.a(dcigettext.o): In function `_nl_find_msg':
/tmp/tools/gcc/gcc-20011126/sparc-sun-solaris2.8/gcc/intl/../../../gcc/intl/dcigettext.c:879: undefined reference to `libiconv'

./intl/libintl.a appears to be different in stage1 and stage2. It looks
as if in stage1 the Solaris <iconv.h> from /usr/include has been used but
in stage2 the <iconv.h> from /usr/local/include (or $prefix/include) has
been used. I.e. the two compilers used in the different stages ("gcc"
vs. "stage1/xgcc -Bstage1/") have different include paths. But the INTLLIBS
that is being substituted into the Makefile is the one from stage1, namely
'./intl/libintl.a', whereas the INTLLIBS value that would result from running
CC="stage1/xgcc -Bstage1/" configure, namely
'./intl/libintl.a -L/usr/local/lib -liconv', is not used anywhere.

The expectation that adding /usr/local/include or $prefix/include to the
include file search path will not change any autoconf results is wrong, IMO.
In particular, the value of INTTLIBS changes.

One possible fix (A) is to have a Makefile for each stage.

Another possible fix (B) is to add -I/usr/local/include (or
-I$prefix/include) to the configuration and stage1 compilation.
Of course then also -L/usr/local/lib (or -L$prefix/lib) must be added
to the LDFLAGS at the same time, otherwise mismatch can occur at other
places.

> The workaround is for the user to configure using
> --with-libiconv-prefix.

Here comes the good news: The newest version of the AM_ICONV macro
(serial AM3) in
ftp://alpha.gnu.org/gnu/gettext/gettext-0.11-pre3.tar.gz
does the equivalent of --with-libiconv-prefix=$prefix by default,
i.e. it searches for iconv.h and libiconv.{so,a} under $prefix. And if
it finds it, it adds -I options to CPPFLAGS. If you use this macro,
the configuration of stage1 should find libiconv if it was already
installed under $prefix previously. So this is a special case of (B).

But if the user gives a --prefix option different from /usr/local, AND
the library is previously installed in /usr/local, then you have a
problem. The BSD people have made it clear that they don't wish
autoconf to search for installed packages in /usr/local. If --prefix
is not given and thus defaults to /usr/local, I have an excuse for
searching there. But if the user has given a different --prefix, as is
the case here, then why the hell does the newly built stage1/xgcc look
in /usr/local, when the original $CC didn't?

Bruno