"Gerald Lee" <glee@force10networks.com> writes:

> 	I used anonymous cvs to get a netbsd-4 source tree.  Using
> build.sh, I ran into a problem building cross tools on our Linux system.
> The issue revolves around dumping the cross gcc specs (tmp-spec), and
> the location of libiconv.  The build hits a point where the cross gcc
> specs are being dumped to a temporary file (tmp-spec), and the step
> fails because it can not load the libiconv shared object.  Our version
> is installed in /usr/local/lib, not /usr/lib.  I've hacked Makefile.in
> such that the offending line starts setting the
> LD_LIBRARY_PATH=/usr/lib:/usr/local/lib environment variable.
> 	My question is, what is the proper way to configure my build
> environment for this situation.  I don't have administrative access to
> the system, so changing where the library is installed is not an option.

The proper way probably is to fix the host system so that one doesn't
need to set LD_LIBRARY_PATH; if iconv is in /usr/local/lib and that's
not in the default search path, iconv isn't really installed properly.
LD_LIBRARY_PATH does not seem to be stripped by build.sh, so you could
perhaps pass it in.  But your fix seems reasonable.

> 	Also, is there a way to build only a particular
> architecture/machine basic set of binaries?  I'm trying to keep my disk
> utilization down, and with some of the architectures/platforms not of
> interest removed, my build dies (that is build.sh ... release) doing
> clean-up and not finding the missing architectures.

build.sh normally builds for a single architecture.  An architecture was
just rmoved, and it's possible there is something leftover either in the
source tree or your object tree.  So you might try rm'ing the offending
objdir bits.   How are you invoking build.sh?