This is the mail archive of the gcc@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: Building of fixincludes with 4.0.1 uses wrong gcc


h.michael.foerster@nexgo.de wrote:
> 1. bootstrapping the gcc 4.0.1 under Sparc/Solaris I found that the
> building in "fixincludes" uses the gcc (with no PATH specification)
> instead of the xgcc build by the last stage. It may crash, it happens on
> my environment, because I've migrated from Solaris 9 to Solaris 10 where
> the includes are not compatible.

It looks like the attached file got chopped off, because I can't see
what the error message is.

There is a problem here, but not the one you suggested.  We can't use
the just built xgcc to build fixincludes, because gcc isn't a usable
compiler until after fixincludes has been built and run.  So we have to
use the host compiler, the same one used to build gcc.  Also,
fixincludes has to be built and run before we can bootstrap gcc.

So the problem here is that fixincludes is being built a second time,
after gcc has bootstraped, and it is being built with the wrong
compiler.  Presumably you used "cc" for the bootstrap?  If the installed
gcc is broken, then you wouldn't have been able to use it to bootstrap
gcc.  If so, cc should have also been used to build fixincludes.  It
would have been used the first time we built fixincludes, but the second
time we build fixincludes, we end up using "gcc" which is wrong.  I took
a quick look at the top level Makefile, but I don't see an obvious
reason why fixincludes is being built twice.  We probably should have a
bugzilla bug report for this.

Oh wait, I see the problem, the first time we build
all-build-fixincludes and the second time we build all-fixincludes.  We
have the same problem with libiberty.

By the way, you can fix your old sol9 gcc by rerunning fixincludes.  We
install a copy of it so it can be re-run after an OS update.  Find the
directory where the old gcc installed the cc1 file (e.g. gcc
--print-file-name=cc1) and then look in the install-tools directory.
Not all old gcc versions have this stuff though, so this only works with
some recent gcc versions.

> 2. A question: The gcc 4.0 uses the built-in specs. Is it correct, that
> a "specs" file will not be used as in the 2.x and 3.x versions of the gcc?

Sort of.

gcc has always had a builtin specs file.  By default, we dumped it to a
file and installed the file, just in case someone wanted to modify the
specs file.  But almost no one did, so most of the time this just made
gcc unnecessarily slower.

So now we changed the default so that the specs file is not installed.
So by default, we use the builtin specs.  You still have the option of
creating and installing a specs file, in case you want to modify it.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


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