Re: "changing search order" warning with libiconv 1.8 (GCC 3.1, Solaris 8)

[Bruno Haible]

[Added bug-gnu-gettext to the CCs because iconv.m4 is documented in
gettext.html.]

Paul Eggert wrote:
> I configured libiconv 1.8 with "./configure --prefix=/opt/reb; make"
> on Solaris 8 (sparc) with GCC 3.1, and ran into the following problem:
> 
> gcc -I. -I. -I../include -I./../include -g -O2 -I/opt/reb/include -fPIC -DPIC 
> -DLIBICONV_PLUG ./iconv.c -x none ../libcharset/lib/localcharset.lo -G -o 
> libiconv_plug_solaris.so 
> cc1: warning: changing search order for system directory "/opt/reb/include"
> cc1: warning:   as it has already been specified as a non-system directory
> 
> A similar warning was generated for every "gcc -c" command.

When you gave the option "--prefix=/opt/reb", the iconv.m4 macro started looking
for an installed libiconv in /opt/reb/lib and /opt/reb/include, found it, and
concluded that -L/opt/reb/lib and -I/opt/reb/include should be used, to be able 
to
compile and link against the library.

The warning is documented in the gcc documentation, section "Directory Options":

    "If a standard system include directory, or a directory specified
     with `-isystem', is also specified with `-I', it will be searched
     only in the position requested by `-I'.  Also, it will not be
     considered a system include directory.  If that directory really
     does contain system headers, there is a good chance that they will
     break.  For instance, if GCC's installation procedure edited the
     headers in `/usr/include' to fix bugs, `-I/usr/include' will cause
     the original, buggy headers to be found instead of the corrected
     ones.  GCC will issue a warning when a system include directory is
     hidden in this way."

In other words, the consequences are undefined if one uses -I/opt/reb/include,
and gcc was configured with --prefix=/opt/reb.

The simple solution for you is to use different prefixes for gcc and for the
applications.

Analysis in detail: If the directory in question is one of the directories on
which fixincludes is run (these are the subdirectories of

    $(SYSTEM_HEADER_DIR) $(OTHER_FIXINCLUDES_DIRS)

in gcc-3.1/gcc/Makefile.in), then you should not install packages in this
directory afterwards, because gcc might use the older header files in its
private gcc-lib/system/version/include/... hierarchy. If, on the other hand,
the directory is not among the fixincluded's, then the warning emitted by
gcc is unfounded.

So in one case it's a user bug, in the other case a gcc bug. In neither case
is it an iconv.m4 / AC_LIB_LINKFLAGS bug.

Bruno