This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 3.4 PATCH: Fix IRIX 6 bootstrap failure


Kaveh R. Ghazi writes:

> I haven't been able to bootstrap irix6.5 on mainline for several days
> because of this:
> http://gcc.gnu.org/ml/gcc/2003-07/msg00433.html
> 
> Since your box works, you must have a later irix6.5 that fixes the
> iconv problem.  I'm curious which micro release you have (use uname -R)

no, I'm using GNU libiconv 1.8 instead (at least on IRIX 6.5.18f and
6.5.20f).  A bootstrap on a different machine (running IRIX 6.5.10m, with
MIPSpro cc instead of gcc and without GNU libiconv) is currently in
progress, and seems not to have hit this problem.

The use of GNU libiconv is giving me loads of other trouble, though:

* It is installed into the same prefix as the bootstrap gcc (/vol/gnu), so
  the bootstrap compiler finds it without specifying any additional flags.
  The new compiler is built for a different prefix, so cannot find it and
  bootstrap fails unless I manually add -L/vol/gnu/lib (and -R/vol/gnu/lib
  on Solaris 2) to LIBICONV and -I/vol/gnu/include (previously to java-warn
  since libiconv used to be used only by the java frontend, recently to
  ALL_CPPFLAGS since its use got more widespread).

* I cannot use --with-libiconv-prefix=DIR for two reasons: it adds
  -I/vol/gnu/include to CPPFLAGS, but (since this is already the prefix
  used by the bootstrap compiler), I would get loads of warnings

cc1: warning: changing search order for system directory "/vol/gnu/include"
cc1: warning:   as it has already been specified as a non-system directory
cc1: warning: changing search order for system directory "/vol/gnu/include"
cc1: warning:   as it has already been specified as a non-system directory

  which even cause some otherwise working configure tests to fail (gcc 3.1
  still is my bootstrap compiler; later versions don't have this problem
  anymore).  Using -isystem instead of -I with sufficiently recent could
  avoid this.  Besides, though the AM_ICONV macro sets CPPFLAGS to
  $DIR/include, the resulting CPPFLAGS are never substituted anywhere in
  gcc/Makefile ;-(

I haven't ever fixed that horrible mess and instead chose to manually fix
up gcc/Makefile to work around this.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]