pre-Aug 4.0-CURRENT worlds and those with pre-GCC 2.95.2 worlds.
The problem with pre-Aug worlds is the installed Byacc and Bison doesn't
have necessary changes to compile either GCC 2.95 or EGCS 1.1.x.
The problem with pre-GCC 2.95 worlds is libgcc is built with the wrong
compiler. See rev 1.17 of src/gnu/lib/libgcc/Makefile (which used to live
in src/gnu/usr.bin/cc/libgcc) + commit messge for details of the requirements.
o Send libmytinfo back to the afterlife. It was revived by mistake,
o Make gnu/lib/libgcc before making lib/libpam. This dependency has
been overlooked in constructing the list,
o make depend before make all. It's by using make depend that the
dependency was found in the first place and we need it to prevent
cleaning everything up before we start,
o Don't specify -DNOINFO -DNOMAN for the libraries target. Let the
target handle it. We can do away with a single run over the libs
if we make everything while we're there and only install the
libraries in the object tree.
build make(1) twice and merge the bootstrap-libraries and libraries
targets.
This change solves the bug where build-tools, compiled against the
includes and libraries built from the sources failed to run on the
host, as was the case with the sigset_t change. With this update, a
buildworld will fail if the tools won't compile on the host. This
is solved in further commits where backward compatibility of the
tools is enlarged.
The libraries target has been fixed. The libraries are now build in
the proper order, satisfying the dependencies. The comment is updated
to reflect this.
The linux module and netboot have been removed from the list of tools.
More to follow.
Reviewed by: bde, imp
All Makefiles now use MACHINE_ARCH for the target architecture.
Unification is required for cross-building.
Tags added to:
sys/boot/Makefile
sys/boot/arc/loader/Makefile
sys/kern/Makefile
usr.bin/cpp/Makefile
usr.bin/gcore/Makefile
usr.bin/truss/Makefile
usr.bin/gcore/Makefile:
fixed typo: MACHINDE -> MACHINE_ARCH
support. I've been building world with these changes for months w/o
ill effect. I've also managed to build the cross tool chain for MIPS
with these patches.
Please note that the extent to which these patches work is largely
dictated by how well our tool chains support the cross compilation.
Building alpha binaries on i386 doesn't work. Supposedly building
i386 binaries on alpha does work, but I've not verified it with these
patches, however.
in time to build inetd. (If you already have /usr/include/tcpd.h, the
build doesn't fail. This mainly affects upgrades and 'make world' from
systems more than a few weeks old)
Move was necessary as libgcc should be built with the freshly built
compiler and thus we must wait until the freshly built bits have been
installed somewhere so we can use them. libgcc presence in gnu/usr.bin/cc/
gets in the way of building the new compiler. We could have either
cd'ed to specific directories w/in gnu/usr.bin/cc/ and built and installed
individual bits, or move libgcc out of the way and let our normal subdir
building process work.
* Don't build libgcc in "bootstrap-libraries:" target it should not be
assumed the currently installed compiler can correctly build libgcc.
(as is the case for g++ 2.7.2 and EGCS' libgcc)
committers. A 'make aout-to-elf' is strongly encouraged. This isn't quite
the end of the line for people who have a real problem with updating yet,
but we've got to get this over and done with. Yes, it's bound to be a
couple of bumpy couple of days.
target (see the previous log message). This works for bootstrapping
from 2.2.7. It won't work for bootstrapping from 2.1.x, but that
fails due to include problems earlier.
probably other versions by spamming ${DESTDIR}/usr/include in much
the same way as `make includes'.
Details for 2.2.7: the bootstrap target has always done a weak spam
of ${DESTDIR}/usr/include; we depend on it not installing any
significant anachronisms (it probably shouldn't touch the headers
at all; however, we may be depending on it for things like the
renaming of ts_nsec to ts_sec in <sys/time.h>). Rev.1.49 strengthens
the spam to everything in src/include. For 2.2.7, this is not
immediately fatal. However, the `make all' step in src/includes
is not followed by a `make clean' step, so new rpc headers are not
generated after we've bootstrapped rpcgen. This causes a fatal
error much later when the old (generated) rpc headers are used with
the current headers (sys/types.h and/or the non-generated rpc
headers).
Details for 2.1.x: the bug is immediately fatal. It gives definition
of errno that is not supported by 2.1.x's libc. The weak spam in the
restored version avoids this problem by not installing errno.h.
(Bootstrapping from 2.1.5 actually breaks much earlier.)
I think the header problems supposedly fixed by rev.1.49 were caused
by using NOCLEAN and having the build fall over when the weakly
spammed headers are active. Minor differences in the layout will
then cause the .depend files to point to nonexistent headers. It
is a feature for symlinks like errno.h -> sys/errno.h to not exist
early.
The other change in rev.1.49 breaks building obj directories if NOCLEAN
is set. It is only safe for _re_building with NOCLEAN set.
try and recurse if the lkm dir exists for some reason but there isn't any
Makefile there. (eg: stray files prevented cvs update -P from removing the
empty dirs)
some tools requiring header files, such as errno.h, that are softlinks.
The mini installation of include files in Makefile.inc1 wasn't doing
the job, so it has been ripped out and replaced with a true make of the
/usr/src/include/ directory (make all and make beforeinstall). I think
the original idea was to save time by not installing unnecessary header
files, but it doesn't really save all that much time.
Also, I have moved a NOCLEAN conditional to cover rebuilding the object
tree 'Rebuilding the ${OBJFORMAT} obj tree' section. This may or may not
be correct but it appears to function properly. If it is not correct we
need to find another way to avoid scanning every single file in the
entire source hierarchy for make restarts.
