From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@cygnus.com>
To: Dave Love <d.love@dl.ac.uk>
Cc: egcs@cygnus.com
Subject: Re: libf2c 
Date: Tue, 03 Feb 1998 21:34:00 -0000
Message-id: <27407.886570581@hurl.cygnus.com>
References: <rzqu3agfqys.fsf@djlvig.dl.ac.uk>
X-SW-Source: 1998-02/msg00143.html

  In message < rzqu3agfqys.fsf@djlvig.dl.ac.uk >you write:
  > I'm afraid I don't understand building Fortran these days, but the new
  > libf2c process doesn't look right to me.  I did a bootstrap, and
  > libf2c was configured with an installed compiler (an older gcc, as
  > this is a Linux box), reading my site autoconf config.site and cache.
  > It was then built with xgcc (as I expected).
Hmmm, that's definitely broken.

What *should* happen is the compiler should 3-stage via "make bootstrap", 
then the runtime libraries (libstdc++, libio, libf2c) should be configured
using the target compiler.

Odds are we've just got a minor goof in either the toplevel make/configure
files or in the libf2c make/config files.


  > Originally the configuration was careful to avoid
  > potentially-misleading autoconf configuration files (including
  > clobbering things with `make clean', contra GNU standards) and ensure
  > it did everything with GCC_FOR_TARGET (or whetever the old make
  > variable was called).
Yup.  All this hackery should be able to be removed with the new
organization modulo bugs we've introduced.


  > I can't immediately point to anything mixing
  > the compilers can break but what work I've done on the runtime has
  > always assumed the target compiler is used generally.
It fails for cross compilers :-)  Which is one of the big benefits of
getting it out of the gcc subdir, it's easier to get these issues dealt
with correctly.

  > [Sorry for getting this stuff wrong in the first place.]
No worries, we'll get it nailed down. :-)

jeff