FreeBSD. This method attempts to centralize all the necessary hacks
or work arounds in one of two places in the tree (src/Makefile.inc1
and src/tools/build). We build a small compatibility library
(libbuild.a) as well as selectively installing necessary include
files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various
places in the tree. We still build on tip of stable and current. I
will work with those that want to support more, although I anticipate
it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at
various stage of implementation, as well as for working together to
positively effect a change for the better.
buildworld. This gives 5-11% percent gain in real buildworld
times on various UP and SMP systems here. I used 4 * hw.ncpu
as an argument to "make -j" in my tests.
glibc which is externally maintained, so GCC ships with these
warnings turned off by default. This is also consistent with
the src/contrib/gcc/c-lex.c,v 1.2 change.
and kgzip(8) from the list of cross-tools during the normal,
non-"make release" buildworld.
Also, don't gratuitously build them, btxld(8) and elf2aout(1)
for native architecture builds, since they have no known
boostrapping issues along the supported upgrade path.
Prodded by: peter
from the source directory. (This mostly affects the RELENG_4's
``make release'' release.5 target, where "rtermcap" build-tool
for release/sysinstall ends up in the source directory and later
steps of release.5 wipe it out.)
Spotted by: jhay
is a compiler tool and needs to be compiled by the host compiler. I've
tested this in i386->sparc cross-build, 4.7->current upgrade, normal
buildkernel target, and normal /sys/i386/compile/GENERIC configurations.
Submitted by: ru
non-cross cases without DESTDIR, that the bin/sh that we're about to
install works. Otherwise, a 'make installworld' without having already
rebooted with a post-signal-fix kernel is a rather big disaster when
important things like /bin/sh coredump.
under way to move the remnants of the a.out toolchain to ports. As the
comment in src/Makefile said, this stuff is deprecated and one should not
expect this to remain beyond 4.0-REL. It has already lasted WAY beyond
that.
Notable exceptions:
gcc - I have not touched the a.out generation stuff there.
ldd/ldconfig - still have some code to interface with a.out rtld.
old as/ld/etc - I have not removed these yet, pending their move to ports.
some includes - necessary for ldd/ldconfig for now.
Tested on: i386 (extensively), alpha
doing the cd. This is done for bootstrap-tools,
build-tools, cross-tools, and the libraries loop.
Reviewed by: ru
Approved by: sheldonh (mentor)
MFC after: 1 week
endless recursion bug similar to the one that has been fixed in
release/Makefile,v 1.698, in advance. A related fix to make(1)
has been committed in make/main.c,v 1.68.
Requested by: bde (who has them merged already)
If there was no CPUTYPE assignment in /etc/make.conf, this would
cause the ``CPUTYPE assignment type'' check to falsely fail.
Reported by: johan
Fixed this by making sure we always pass the non-empty CPUTYPE.
Also make sure we use the correct set of share/mk files in our
test.
TARGET_ARCH and TARGET. This is problematic when one has the =
(unconditional) type of assigment for CPUTYPE in /etc/make.conf.
(This would override what was set on the command line to "make
buildworld".)
Add a (horrible) kludge to Makefile.inc1 to check the type of
assignment for CPUTYPE (only for those who attempts to set it to
a different value). Fix an example make.conf. Fix the kernel's
build-tools target (aicasm only at the moment) to catch up with
bsd.cpu.mk,v 1.15 (BOOTSTRAPPING replaced with NO_CPU_CFLAGS in
Makefile.inc1's BMAKE).
Reviewed by: jhb
bsd.cpu.mk doesn't have to worry about compilers other than the current
version.
- Allow TARGET_CPUTYPE to override CPUTYPE in bsd.cpu.mk.
- Treat an empty CPUTYPE the same as an undefined CPUTYPE.
- For buildworld, buildkernel, etc., define TARGET_CPUTYPE to CPUTYPE for
native builds and define it to be empty for cross-builds.
TARGET_CPUTYPE is only defined if it is not already defined via the
commandline or environment.
This only affects the -current early adopters and developers who have
done a 'make world' in the last few weeks and as a result installed a
gcc-3.1 version of /usr/bin/c++ but without the corresponding library
support that this now requires. This is a temporary hack that should be
deleted within a few weeks. In this case we will use the existing
gperf/groff one last time around for the early stage1 bootstrap. (This
isn't so bad, because we were unconditionally using the host one before)
