| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
building the libraries target. pcvt is i386 specific.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildworld doesn't break because the host doesn't have any
games installed,
o Add a new build stage: TMAKE. TMAKE builds all the build-tools
targets in the respective makefiles. Note that these targets
don't use the bootstrap tools,
o Add elf2exe to the bootstrap-tools when cross-building Alpha on
other platforms,
o Add ${WORLDTMP}/usr/games to TMPPATH,
o Remove ${WORLDTMP}/usr/bin even when NOCLEAN is defined. This
prevents using any bootstrap-tools previously installed. Most
importantly, it prevents using the cross-compiler when we still
need the native compiler.
The current stages are BMAKE, TMAKE, XMAKE and IMAKE in that order.
BMAKE builds bootstrap-tools that either solve compatibility problems
or are needed as cross-tools,
TMAKE builds the support tools necessary by some parts in the source
tree and also performs the cleandir and par-obj targets,
XMAKE builds the includes, libraries and everything (resp.), and
IMAKE installs the world. This stage needs further work if it's to be
used to install -current over -stable for example.
This is the last major update towards cross-building.
|
|
|
|
| |
while SUPFILE1 or PORTSSUPFILE are defined.
|
| |
|
|
|
|
|
|
| |
o Don't set CFLAGS in the bootstrap env. It is very likely to be
overridden my any CFLAGS setting in /etc/make.conf. Setting it
here is almost useless. So far, it doesn't seem necessary.
|
|
|
|
|
|
| |
The boot2 for pc98 is still a.out program.
I made the original patch, and many problems were fixed by Marcel Moolenaar.
|
|
|
|
|
|
| |
This should fix make release.
Reported by: jhay, phk
|
|
|
|
|
| |
has been defined.
o Make libraries before making depend.
|
|
|
|
| |
for development. :-/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o Build tools before doing anything in or with the object tree.
o Tools don't use the object tree any more, but have there object
tree located in the temp. world.
o Use the proper make env. for cleaning and building the object tree.
o Don't create kernel include subdirectories in the temp. world. These
are removed later on and replaced by symlinks.
o Change the layout of the object tree:
The temp. world now is /usr/obj/${MACHINE_ARCH}${.CURDIR}/${BUILD_ARCH}.
/usr/obj can be set/changed by using MAKEOBJDIRPREFIX, and {.CURDIR}
obviously depends on where the source tree is located. MACHINE_ARCH
is the arch. for which the world is to be build and BUILD_ARCH is the
arch. on which we are building.
The object tree now is /usr/obj/${MACHINE_ARCH}${.CURDIR}.
This allows concurrent cross-builds and allows the object tree to be
shared on different archs., each doing the same cross-build. This of
course assumes that the output on Alpha (for example) is the same as
the output of an Alpha cross-build on i386 (for example).
The use of NOCLEAN is is still dangerous, but should be usable in many
more situations than before. It should now be possible to safely
restart an interrupted build with NOCLEAN without side-effects. Because
the tools don't share the object tree with the normal (cross-build), no
tools have to be rebuild.
|
| |
|
| |
|
|
|
|
|
| |
o If you can't beat them, join them: use symlinks to populate the obj
tree. This avoids using mtree.
|
|
|
|
|
|
|
|
|
| |
non-root cross-building.
o Makefile.inc0 is not used anymore.
o The legacy aout build has been removed.
o Selectively build tools *before* building includes/libraries.
o Avoid using mtree to populate the obj tree.
|
|
|
|
| |
along with the misplaced entries that it was next to.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Submitted by: Boris Popov <bp@butya.kz>
|
|
|
|
| |
Reviewed by: mdodd
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
comment. Fixes broken make world.
|
|
|
|
| |
fixes the make buildworld breakage in sys/boot/arc/loader.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
sure what is reported to the user is accurate.
Stolen From: mharo
|
| |
|
| |
|
|
|
|
|
| |
While I'm here - reorder crypto directories to better support
dependancies. Perl and others like it better that way.
|
|
|
|
|
|
|
|
| |
Tested with a make world.
PR: misc/4395
Submitted by: J Wunsch
Reviewed by: bde
|
|
|
|
|
| |
PR: bin/11035
Submitted by: Chris Costello <chris@holly.dyndns.org>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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)
|
|
|
|
| |
hashed out with his gracious help.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
| |
which aren't the alpha. Test for MACHINE_ARCH == i386 rather than
MACHINE_ARCH != alpha.
|
|
|
|
| |
being build as part of a bootstrap.
|
|
|
|
| |
with DESTDIR set to an NFS-mounted file system.
|
| |
|
| |
|
|
|
|
|
|
|
| |
cases are now handled in lib/libcrypt, depending upon if
secure/lib/libcrypt/crypt-des.c exists)
Reviewed by: Mark Murray
|