Subject: Re: Foreign Build w/ USE_NEW_TOOLCHAIN: binstall doesn't use ${STRIP}
To: Chris Jepeway <>
From: James Chacon <>
List: tech-toolchain
Date: 09/25/2001 15:18:06
There are probably some other tools which aren't in the toolchain now that
should be if you really do want to support a foreign build. i.e. groff/nroff
comes to mind.


>> : binstall uses the native strip.  One fix might be to change the defn
>> : of INSTALL in 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`
>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 would pick up the tools
>directly from $(TOOLDIR)/$(MACHINE_GNU_PLATFORM) as in
>    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 <>.
>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?