bootstrap w/o symlink

Donn Terry
Sun Feb 28 18:15:00 GMT 1999

Jeffrey A Law wrote:
>   In message < >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
files are compounded into the makefile, it must appear literally
as well in the files (where needed).

As to other ways out of it:
1) If the configure process is changed so @...@ substitution occurs
on the 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.)  Makefile handles the stages,
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


Donn Terry        
Softway Systems, Inc.
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951

More information about the Gcc-patches mailing list