Subject: Re: egcs 1.0.2 and netbsd.
To: matthew green <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-toolchain
Date: 03/25/1998 11:25:21
>it builds basically the same as gcc currently builds, just from
>the egcs sources.

It would be much, much better if we didn't do this.

The first (and biggest win) is to do the same split,
src/gnu/dst/egcs-1.02 vs. gnu//usr.bin/egcs, that Gordon Ross &c did
with gdb (and are doing with binutils.).  That makes life _so_ much
simpler when configuring cross-compilers: you can rerun a GNU
configure in a subdir of the gnu.dist/ tree and get all our local

This would be a Major Win, imho, given how hard it's been for people
to build cross-compilers from the Official Supported NetBSD Compiler

The second is that (again for cross-compile setups, or even when
installing and regression-testing new versions), it really is *much*
nicer to build the backend and install it and spec files under
/usr/libexec/gcc-lib/$target/version (or egcs-lib, whatever).

The third is that the backend insn library is really part of ``the
compiler'', both hosted and non-hosted (freestanding).  
Stuff like the {add,sub,mul,div}di3 insns are part of ``the
compiler'': the libkern and libc versions of those should be nuked
from orbit. They really belong to a specific version of gcc
(though the semantics are unlikely to change).

Even some of the Core members who helped do the libkern/libc reorg of
what should be libgcc1 would agree with this.  Besides, if we do the
"--freestanding" thing, it can also eliminate all of stdlibs except
these builtin backend libs.

>   - we *should* install a specs file by default.  I've griped about this
>     in our gcc for a while now.
>maybe you can do this after it's in the tree.

Um, i think after egcs is in the tree is kinda too late.  if the point
of installing a specs file to aid cross-compiling &c, then we really
should be installing using the `native' backend hierarchy.  (see above;)

>   - the directory search mechanisms need some pruning using #ifdef
>     CROSS_COMPILE (I'll probably look into doing this) so that some funky path
>     like /usr/libexec/2.8.0/NetBSD isn't searched when native, but the
>     appropriate cross directories are searched on cross.
>uh, .... huh ?

i think this would just fall out if we installed the `native' egcs
(our cc) using the "standard" backend hierarchy. if I've understood
todd correctly.