build-tools target and by the actual target. In a cross-building situation
proj.o is both a native object and a cross-object (i.e., for the target
arch) and thus doesn't work. Creating seperate opjects from the same
source file solves this...
This patch may also fix the following issue:
> it looks like -DNOCLEAN doesn't work too well.
> cd /usr/src/gnu/usr.bin/cc/f771; make build-tools
> make: don't know how to make /usr/obj/usr/src/i386/usr/include/stdarg.h. Stop
This seems caused by wrong dependency information. Dependency
information shouldn't be created for build-tools sources.
Submitted by: marcel
This is a new feature of groff and is a html driver for groff.
From the manual page:
"grohtml translates the output of GNU troff to html."
This is very interesting for people working on documentation.
* Remove "why we need this decl..." comment. The `matcher' variable
is defined in *grepmat.c files in the original distribution, which
we did not import.
It is being re-imported here, to keep our long source change history with
this source continuous.
src/contrib/grep will be deleted some time in the very near future.
If one wishes to anchor the compiler toolchain tree somewhere other than /,
all one needs to do is set "TOOLS_PREFIX" to a different rooting.
Submitted by: marcel (in a different format and reworked by me)
of changing the search dirs. This also removes an used search dir,
removes unneeded redundancy, and a bugus dir we enherited on the i386
by baseing off of svr4.h.
We went from:
install: /usr/libexec/(null)
programs: /usr/libexec/<OBJFORMAT>/:/usr/libexec/:/usr/bin/:/usr/libexec/
libraries: /usr/libdata/gcc/:/usr/libexec/:/usr/ccs/lib/:/usr/lib/
to:
install: /usr/libexec/(null)
programs: /usr/libexec/<OBJFORMAT>/:/usr/libexec/
libraries: /usr/libexec/:/usr/lib/
happened as it was working around problems elsewhere (ie: binutils/ld
not doing the right thing according to the ELF design). libcrypt has
been adjusted to not need the runtime -lmd. It's still not quite right
(ld is supposed to work damnit) but at least it doesn't impact all the
users of libcrypt in Marcel's cross-build model.
The target machine is represented by TARGET_ARCH. MACHINE_ARCH always
represents the host machine. When TARGET_ARCH is not defined, it is
assumed to be equal to MACHINE_ARCH. This means that we're building a
native toolset by default. We're creating cross-compilation tools when
MACHINE_ARCH != TARGET_ARCH.
TARGET_ARCH is defined when building binutils as part of the bootstrap
build and is set to reflect the architecture we're currently cross-
building. With this change binutils is ready for cross-building.
