Subject: Re: egcs 1.0.2 and netbsd.
To: matthew green <mrg@eterna.com.au>
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
changes.
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
Source(tm).
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.