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]

Re: bootstrap w/o symlink


Jeffrey A Law wrote:
> 
>   In message <36C86940.AED6168A@verinet.com>you write:
>   > Below are the patches I've found necessary to allow a
>   > make bootstrap on a system w/o symlinks.
>   >
>   > For gcc:
>   > This fixes a bug with `` substitution marks, and also some additional
>   > changes required to make builds withoug symlinks work correctly.
>   >
>   > For CHILL: don't override CC; the default one is correct for staged
>   > builds.  ($(CC) is the native compiler and/or doesn't get the relative
>   > pathname).
>   >
>   > For g77: provide a working HOST_CC by computing the relative pathname.
>   > (@cc_set_by_configure@ didn't work: is substitution too late?  Changing
>   > HOST_CC at the top level breaks other things).
> Ugh.  I'd really like to see us unify this stuff.  It's absurd to have
> 3 different means to get the right compiler.
> 
> But I don't want to do now either -- ie, I'd much prefer to wait until after
> egcs-1.2 branches before we start ripping apart the configur/make stuff.
> 
> I'd say let's hold off.  Or at least look into how difficult it would be to
> unify selecting the right compiler first.  If it's not too hairy to unify
> selection of the right compiler, then dealing with this problem would be
> relatively straightforward afterwards.

The proposed patch simply finishes a job that was started but not
completed (or has rotted since... don't know which since I wasn't
there).  I suspect it was never finished, given the comment:

# Flags to pass to recursive makes.
# CC is set by configure.  Hosts without symlinks need special handling
# because we need CC="stage1/xgcc -Bstage1/" to work in the language
# subdirectories.
# ??? The choices here will need some experimenting with.

In terms of a unified solution: the value must be computed along
the way during the various build stages, which means that some
method must exist to compute it.  As far as I can tell, there is
only one method (the "echo $(CC) |..." junk), but it must appear
in three differnet ways:

Because it's a `` substitution, it must appear both quoted and
unquoted, so it can be used both directly and nested inside ``.
Without $(), these must be different strings.  Since 
@...@ substitution appears to occur before the Make-lang.in
files are compounded into the makefile, it must appear literally
as well in the Make-lang.in files (where needed).

As to other ways out of it:
1) If the configure process is changed so @...@ substitution occurs
on the Make-lang.in files (or if I biffed it when I tried that),
then we can deal with with that reasonably.  Is that a decent
direction to go?

2) To really clean it up requires that the Makefile change between
stages, or that the value of $(CC) be passed in on the command line
(but then there's an issue of a default).  Whether that can be
done decently in the context of POSIX make, I'm not sure.  (It
probably DOES require a recursive make... not something high on
my list of favorite things.)

3) Another alternative is that Makefile be a "trivial" (yeah, sure)
wrapper for (e.g.) gcc.mk.  Makefile handles the stages, gcc.mk
knows how to handle any one stage.  (This is probably a pretty
massive change.)

In any case, I don't see that fixing the current problem with the
fairly simple changes proposed here makes things worse, and it does
make building on systems without symlinks harder if they aren't
applied.

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================


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