Todd Vierling <tv@NetBSD.ORG> writes:

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

I think there's a difference of vision here.  You're thinking in terms
of "the native cc" being targeted for only the native CPU.  Yes?

I'm thinking of a world where "the native NetBSD compiler" and the
whole toolchain, includes support for setting up cross-compilation, as
part of the "supported" NetBSD environment.  Evntually, maybe with
make targets for cross-compile toolchains.

In that world, having a /usr/libexec/cc/ hierarchy does make a lot of
sense.  It also makes cutting over between versions (and running two
in parallel) a heck of a lot eaiser.



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

Yes we can, when we next bump the libc major number. And we should.

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

That would make me happier.  Especially if we use the "reach-over"
method of integration. Ideally with makefiles which allow users to
build "cross-compile" environments, using reach-over.  that way
"cross-compilers" of the Official NetBSD Supported Compiler(tm) could
install the standard gcc/egcs search hierarchy.   (tho' i'm not
expecting all that right now, of course.)

As it stands, searching in the "standard" gcc places is kinda pointless.