Subject: Re: different behaviour of system cc and TOOLDIR/cc
To: Todd Vierling <>
From: Frederick Bruckman <>
List: tech-toolchain
Date: 06/09/2003 09:25:51
On Mon, 9 Jun 2003, Todd Vierling wrote:

> On Sun, 8 Jun 2003, Frederick Bruckman wrote:
> : > 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!).
> :
> : And the includes? When you compile a cross-compiler with
> : --with-headers=${DESTDIR}/usr/include, it stuffs them into
> : ${TOOLDIR}/${MACHINE_GNU_PLATFORM}/sys-include. That directory isn't
> : in the paths, however, shown by ${TOOLDIR}/bin/gcc -print-search-dirs.
> Without --with-headers (and I should hope that src/tools/toolchain hasn't
> been modified to put this in the configure args![*]), it will look in
> ${TOOLDIR}/${MACHINE_GNU_PLATFORM}/include (as an analogue to .../lib).
> I believe this directory won't show up in -print-search-dirs unless it
> exists.
> [*] The toolchain created by src/tools/toolchain should NOT have any
>     specific ${DESTDIR} compiled into it.  It should be position independent
>     to ensure it doesn't pick up strays!

--with-headers and --with-libs don't change the search path, by the
way. They copy the target libs and headers into the compiler's search
path: ${prefix}/${platform}/sys-include and ${prefix}/${platform}/lib.
That appears to be the "supported" way to build a cross-compiler.

As I said, I understand why the bootstrap compiler doesn't and
shouldn't have access to any target libs and headers, but it would
make sense to me to either stuff them in later, or as I suggested,
configure yet another toolchain (with i18n and shared bfd).

Consider, the base sources were extensively modified to work with a
no-defaults compiler. Do we really want to do that to "xsrc", which
currently builds essentially out-of-the-box, the top-level makefile
being essentially a handful of scripts?