On Fri, 6 Jun 2003, Matthias Drochner wrote:

: The same with "tools" doesn't work:
:
: $ /usr/tools/bin/i386--netbsdelf-gcc -v -shared -o mist.so xxx.o
: Reading specs from /usr/tools/lib/gcc-lib/i386--netbsdelf/2.95.3/specs
: gcc version 2.95.3 20010315 (release) (NetBSD nb4)
:  /usr/tools/lib/gcc-lib/i386--netbsdelf/2.95.3/collect2 -m elf_i386 -sha
: red -o mist.so crtbeginS.o -L/usr/tools/lib/gcc-lib/i386--netbsdelf/2.95
: .3 -L/usr/tools/i386--netbsdelf/lib xxx.o crtendS.o
: /usr/tools/i386--netbsdelf/bin/ld: cannot open crtbeginS.o: No such file
:  or directory

This is because src/tools/toolchain was created specifically for compiling
the NetBSD tree -- i.e. it *assumes* that you will be specifying where to
get the files from /usr/lib via a -B option.  The reason for this was to
prevent accidentally picking up a stray somewhere like
/usr/local/${MACHINE_ARCH}-netbsd/lib/crt*.o; rather, this keeps it in
isolation.

You might also note that it's standard practice for a GCC cross-compiler to
look in its ${libsubdir} for the "standard" system goop rather than /usr.
This is because a GCC configured to be a cross-compiler deliberately avoids
picking up /usr/include and /usr/lib -- as they are nearly always Wrong for
a build with that cross-compiler.  The place where the $TOOLDIR-based gcc
would find such files automatically, then, would be
${TOOLDIR}/${MACHINE_ARCH}-netbsd/lib (try plonking them in there and see!).

So it's actually appropriate to add -B to get the startfiles and system
libraries in this case....

-- 
-- Todd Vierling <tv@pobox.com>