Subject: RE: question(s)
To: Greg Troxel <>
From: Gerald Lee <>
List: tech-toolchain
Date: 07/20/2007 10:16:02
Greg Troxel wrote:
>"Gerald Lee" <> writes:
>>      I used anonymous cvs to get a netbsd-4 source tree.  Using,=20
>> 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
>> is installed in /usr/local/lib, not /usr/lib.  I've hacked
>> such that the offending line starts setting the
>> LD_LIBRARY_PATH=3D/usr/lib:/usr/local/lib environment variable.
>>      My question is, what is the proper way to configure my build=20
>> environment for this situation.  I don't have administrative access
>> the system, so changing where the library is installed is not an
> 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, so you could
perhaps pass it in.  But your fix seems reasonable.
        I agree about the installation, but what surprised me was that
I set the variable in my shell and exported it (LD_LIBRARY_PATH), and
expected it to be propagated all the way down (OK, so it was just a
hope ;).  uname on the build host gives:
Linux <hostname> 2.4.21-37.ELf10 #4 SMP
        Were I in a postion to set the location of the libiconv, we'd
be running something a bit more contemorary.
>>      Also, is there a way to build only a particular
>> 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 ... release) doing clean-up and not
>> finding the missing architectures.
> 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
> objdir bits.   How are you invoking
./ -a powerpc -m evbppc -D /work/sw/gll/NetBSD_4/cross-dest \
        -D /work/sw/gll/NetBSD_4/cross-dest \
        -O /work/sw/gll/NetBSD_4/cross-obj \
        -T /work/sw/gll/NetBSD_4/cross-tools \
        -V BLDX11=3Dno -U kernel=3DEV64260 release
        Actually, I have this in a script, and build the tools with
'tools' substituted for 'release'.  The error, generated by the release
build is:
nbmake: "/sites/sjc/work/sw/glee/NetBSD_4/src/lib/libarch/Makefile" line
7: Could not find
nbmake: "/sites/sjc/work/sw/glee/NetBSD_4/src/lib/libarch/Makefile" line
7: Could not find
nbmake: "/sites/sjc/work/sw/glee/NetBSD_4/src/lib/libarch/Makefile" line
7: Could not find
nbmake: Fatal errors encountered -- cannot continue
        Granted, I'm doing something a bit off the beating path (if
not down right odd), so not totally surprised.  I'm using .cvsignore
to keep my disk footprint down.  So, I've elmininated alpha, sparc, arm
and so on from my tree.  My {pre,a}sumption was that removing the =20
directories would be sufficient.
- bob