> : binstall uses the native strip.  One fix might be to change the defn
> : of INSTALL in bsd.own.mk to put STRIP in binstall's env.  This patch
> : instead changes binstall directly.
> 
> I'll put it in the environment instead.  The reason for that would be
> because I want to avoid arch-dependent binaries where possible (note that
> $TOOLDIR/bin contains only one lint, binstall, mkdep, ...).
Well, does it make sense, then, to do both?  After all,
even if you don't change the compiled path to strip inside
binstall, leaving it at /usr/bin/strip is still "arch-dependent."
Whereas, if you do change strip's path to $(TOOLDIR)/bin/whatever-strip,
then at least it's right for the simplest case.  That way, you
could add $(TOOLDIR)/bin to a shell's PATH.

Though, mebbe the way to get PATH happy is with a big pile of
wrappers that switch off according to MACHINE_GNU_PLATFORM or
somesuch.  As in:

    #!/bin/sh
    TOOLDIR=${TOOLDIR:-/extra/tools}
    ME=`basename $0`
    MACHINE_GNU_PLATFORM=${MACHINE_GNU_PLATFORM:-i386--netbsdelf}
    exec $TOOLDIR/$MACHINE_GNU_PLATFORM/bin/$ME "$@"

The defaults for TOOLDIR and TARGET could come from mk.conf.
This script would then wrap all the arch-dependent tools now
in $(TOOLDIR)/bin.  And bsd.own.mk would pick up the tools
directly from $(TOOLDIR)/$(MACHINE_GNU_PLATFORM) as in

    CC?=	${TOOLDIR}/${MACHINE_GNU_PLATFORM}/bin/gcc
    MKDEP?	CC=${CC} ${TOOLDIR}/bin/mkdep

So you'd get:

    o  a dir that can go in a shell path for interactive development
       (and for quick-fix Makefile trickery)

    o  you can switch your dev environment by setting an envariable

    o  the build process skips the overhead of the wrapper scripts

Chris <jepeway@blasted-heath.com>.

Say, now that USE_NEW_TOOLCHAIN is moving along as the default
for -current, is current-users a more appropriate place for non-guts
questions about the toolchain?