On Wed, 25 Mar 1998, Jonathan Stone wrote:

: >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.

Matt said something to me about using the gdb reachover method... maybe he
can clarify?

: 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).

This doesn't matter in a native environment--the extra pathnames are just
extra pathnames.  In a cross environment, you won't be using
/usr/{bin,libexec} directly, so then you'd want the extra cruft.  It's just
a matter of setting the install directories and search directories properly.

I'd rather *NOT* see a /usr/libexec/gcc-lib/... hierarchy for a native
compiler, nor would I like to have such a directory searched.  It's more
clutter than necessary.

: 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

Can't remove them completely from libc now: "binary compatibility."

: >   - 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

No, the point is to aid customization:  the specs file will always exist,
and just be a dump of "gcc -dumpspecs".  I'm mixed in opinion now about this
after talking to a few people, though.

: >   - 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.

Right, install using our standard hierarchy, but leave a provision to use
the extended pathnames if on a cross compile.  Do a ktrace on cc sometime
and watch where it looks for executables:  pretty odd ones there, don't you
think?  Note the ones that are subdirectories of /usr/libexec.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)