through scanning its output as ldd(1) returns a non-zero status only
for really abnormal conditions such as an improper file format.
Now cp(1) won't get bogus "not" and "found" arguments if a lib
is missing. [1]
- Don't guess if an element of a complex pipeline is assigned to the main
shell or a sub-shell. Namely use stdio, not vars, to pass lists out from
loops. If using vars, there's the risk that a loop will run in a sub-shell
and the list won't make it to the main shell. It appears that braces and
parens give only limited control over the issue while stdio always works
as intended. Apply this solution to both $progs and $libs for consistency,
although I've failed to go without it only in the $libs part.
Requested by: emaste [1]
I.e., not only copy them to a scratch dir, but also make them use saved
copies of libraries and locale files. That gives us several benefits:
1) ABI breakages should no longer affect installworld over the live system.
2) It becomes safe to run installworld while still running the old kernel.
However, it can be reasonable to save the old /rescue before that to be
able to run the old reboot(8), as the new binaries are rather likely to
fail with the old kernel. Anyhow, it's now possible to upgrade a system
in a single reboot _reliably_.
3) With a bit of hackery around rtld(8), it becomes possible to do destructive
cross-installs, e.g., i386->amd64 over the live system.
The only shared item left between the old and new systems is rtld(8),
which cannot be run from a saved copy easily because its full
pathname is stored in the respective field of each ELF executable.
(In theory, that field could be overridden, e.g., from the environment,
but this can lead to security issues.) That's why a destructive
cross-install isn't possible w/o hackery yet.
Fruitful ideas by: ru
Reviewed by: ru
Tested with: audit(4)
the threading libraries is built. This simplifies the
logic in makefiles that need to check if the pthreads
support is present. It also fixes a bug where we would
build a threading library that we shouldn't have built:
for example, building with WITHOUT_LIBTHR and the default
value of DEFAULT_THREADING_LIB (libthr) would mistakenly
build the libthr library, but not install it.
Approved by: re (kensmith)
their dependency on libc and its versioned symbols. For that to work,
libc needs to be built before any other shared library that might depend
on it. Add necessary glue to make that happen.
Warning, after symbol versioning is enabled, going back is not easy
(use WITHOUT_SYMVER at your own risk).
Change the default thread library to libthr.
There most likely still needs to be a version bump for at least the
thread libraries. If necessary, this will happen later.
lib32 build somewhat. Specifically, instead of spamming
${CC} et al with -I${LIB32TMP}/usr/include which can be
harmful (as has been demonstrated by the ncursesw WIP),
use slightly different approach to achieve the same goal.
This also simplifies things a bit.
Prodded by: rafan
- Remove libnetgraph from the list of prebuilt libraries as
no other library depends on it (snmp_netgraph.so does not
count as we don't build it in the "libraries" target).
- Restore libssh dependencies when compiling with Kerberos
support.
I found one bug. Pass our idea of TARGET_ARCH and TARGET down to
XMAKE, the cross-tools make. Previously it worked because usually
TARGET_ARCH was specified on the initial make's command line.
This should also allow us to simplify the "universe" target, which
I'm currently testing.
TARGET_ARCH correctly. Now it does, even for pc98. We should suggest
TARGET=foo in preference to TARGET_ARCH because the former is
unambiguous and the latter isn't, so update the docs.
This means that a long standing gripe I've had with this comes to a
close. I can build pc98 w/o specify both things. make TARGET=arm
works (rather than trying to build a arm:amd64 image and dying badly
in the attempt).
If you specify only TARGET_ARCH, then you get the old behavior.
# we can likely simplify the UNIVERSE target now to use this, but I'm not
# up for breaking that tonight :-).
# We should consider adding some kind of sanity check for TARGET_ARCH
# and TARGET.
environment for cross building (the same one you'd get interactively
in make buildenv). This cannot be a simple
make -f Makefile.inc1 -V WMAKEENV
because in PATH is not set correctly unless one takes a trip through
the Makefile/Makefile.inc1 indirection, the logic of which is too
large to reproduce outside of Makefiles.
to post January 26 systems where gensnmptree(1) code was already fixed,
there was a timeframe between February 14 and February 27 when
usr.sbin/bsnmpd/ including gensnmptree was disconnected from build, so
if you upgraded in this timeframe, you ended up with the 700014 system
but still with a buggy gensnmptree binary. This also means not being
able to buildworld now.
Reported by: jhb
Attention: harti, keramida
- <netipx> headers [1]
- IPX library (libipx)
- IPX support in ifconfig(8)
- IPXrouted(8)
- new MK_NCP option
New MK_NCP build option controls:
- <netncp> and <fs/nwfs> headers
- NCP library (libncp)
- ncplist(1) and ncplogin(1)
- mount_nwfs(8)
- ncp and nwfs kernel modules
User knobs: WITHOUT_IPX, WITHOUT_IPX_SUPPORT, WITHOUT_NCP.
[1] <netsmb/netbios.h> unconditionally uses <netipx> headers
so they are still installed. This needs to be dealt with.
gensnmptree utility is required at "make depend" time, because it
is used to generate `oid.h' for bsnmpd.
This means that all versions of HEAD before 2004/01/23 16:22:49 need
gensnmptree as a bootstrap util when it's not already installed as
part of the base system. The first __FreeBSD_version that we can
assume this can work is 700014 which happened after the gensnmptree
change (in -r 1.263 of `src/sys/sys/param.h', at 2006/02/17 14:14:15).
For __FreeBSD_version values before 700014 add gensnmptree to the
bootstrap tools, to allow upgrades from versions of FreeBSD before
that date.
Approved by: ru, harti
in the delete-old and check-old targets.
We don't install a lib (libXY.so.Z) as a link, but an user may have created
something like this. This is dangerous if this link points to a different
version of the lib. So check for a link also in the *-lib targets (an
annoyed user which absolutely wants this redirection of a lib should use
libmap.conf instead of a link).
A directory can also be a link, but in this case just echo a message to
remove it by hand.
similar the the Solaris implementation. Repackage the krb5 GSS mechanism
as a plugin library for the new implementation. This also includes a
comprehensive set of manpages for the GSS-API functions with text mostly
taken from the RFC.
Reviewed by: Love Hörnquist Åstrand <lha@it.su.se>, ru (build system), des (openssh parts)
Switch strncpy to strlcpy suggested by gad and issue found by pjd.
Add to uname(3) man page describing:
UNAME_s
UNAME_r
UNAME_v
UNAME_m
Add to getosreldate(3) man page describing:
OSVERSION
Submitted by: ru, pjd/gad
Reviewed by: ru (man pages)
FreeBSD machine. To do this add the man 1 uname changes to __xuname.c
so we can override the settings it reports. Add OSVERSION override
to getosreldate. Finally which Makefile.inc1 to use uname -m instead
of sysctl -n hw.machine_arch to get the arch. type.
With these change you can put a complete FreeBSD OS image into a
chroot set:
UNAME_s=FreeBSD
UNAME_r=4.7-RELEASE
UNAME_v="FreeBSD $UNAME_r #1: Fri Jul 22 20:32:52 PDT 2005 fake@fake:/usr/obj/usr/src/sys/FAKE"
UNAME_m=i386
UNAME_p=i386
OSVERSION=470000
on an amd64 or i386 and it just work including building ports and using
pkg_add -r etc. The caveat for this example is that these patches
have to be applied to FreeBSD 4.7 and the uname(1) changes need to
be merged. This also addresses issue with libtool.
This is usefull for when a build machine has been trashed for an
old release and we want to do a build on a new machine that FreeBSD
4.7 won't run on ...
by a user. Instead, add individual checks as dependencies to
the main "installcheck" target. Make sure that installkernel
etc. depend on it (including the UID/GID checks).
bsd.incs.mk, and use it when installing 32-bit compat libraries
on amd64. This causes it to *not* overwrite native headers with
i386 versions, which was the case with <fenv.h> and <vgl.h>.
PR: amd64/83806
Prodded by: bde
MFC after: 1 week
Reported by: scottl
I'm not very fond of using the non-standard lockf(1) here, but I
have no better idea at the moment. NetBSD uses ln(1) to create a
lock file, but this approach can result in a deadlock if make is
interrupted, leaving an orphaned lock file.
are called (wrapped in ".if make(...)"). This may reduce the amount of
memory needed for all other targets (the file lists are already large
and they will grow further).
- Be verbose in the batch case of the delete-old part too.
- Add a note about the organisation of the sections.
- Expand shell globs (they worked in a previous version of the delete-old
target, but not in this one).
- Use the correct way of checking for a native environment. [1]
- Add some more obsolete files.
- Fix some bad english. [1]
Suggested by: ru [1]
Approved by: mentor (joerg)
- removes obsolete files/dirs or libraries.
- works in interactive (default) and batch mode
- respects DISTDIR
- documented in UPDATING and build(7)
The head of the file ObsoleteFiles.inc contains instructions how to add
obsolete files/dirs/libs to the list. Obviously one should add obsolete
files to this list, when he removes a file/dir/lib from the basesystem.
Additionally add check-old target:
- allows re@ to check if a file on the obsolete list resurfaces
Design goals:
- allows full control by the user (default interactive mode)
- possibility of scripted removal of obsolete files (batch mode)
- opt-in removal of files (explicit list of files)
- seperate removal of libs (2 delete targets)
Important design decissions:
- structured list of files to remove instead of a plain text file:
* allows to remove additional files if a NO_foo knob is specified
without the need to change the targets (no NO_foo knob is respected
yet)
- not using mtree like NetBSD does:
* mtree doesn't has an interactive mode
Discussed on: arch (long ago), current (this year)
Additional input from: re (hrs)
Approved by: mentor (joerg)
native and foreign architectures and comparing products).
They eliminate most of the differences caused by different
object directory paths, timestamping, and identification.
(Note WORLDTMP was renamed to ${OBJTREE}${.CURDIR}/tmp.)
introducing the disk formats for _RuneLocale and friends.
The disk formats do not have (useless) pointers and have 32-bit
quantities instead of rune_t and long. (htonl(3) only works
with 32-bit quantities, so there's no loss).
Bootstrap mklocale(1) when necessary. (Bootstrapping from 4.x
would be trivial (verified), but we no longer provide pre-5.3
source upgrades and this is the first commit to actually break
it.)
intent was (and still is) that if a user has say
CPUTYPE=i686 set in /etc/make.conf, we don't print
the assignment type warning unless TARGET_CPUTYPE
is overridden.
Unfortunately, the implementation was buggy, and
only recent changes to bsd.cpu.mk that swapped
canonical and alias values of some CPU types made
the bug apparent.
Here's what happens here.
- CPUTYPE=i686 is set in /etc/make.conf,
- bsd.cpu.mk reset it to "pentiumpro",
- Makefile.inc1 compares this canonical value
with the result of the following test,
make -f /dev/null CPUTYPE=pentiumpro -V CPUTYPE
and expects the result to be "pentiumpro" too,
but "i686" is returned, here's why. We have two
CPUTYPE variables, global, set to "i686" in
/etc/make.conf, and command-line (of a higher
precedence), set to "pentiumpro".
The following part of bsd.cpu.mk,
. elif ${CPUTYPE} == "i686"
CPUTYPE = pentiumpro
which is responsible for converting aliases to
canonical values, sees the value of the CPUTYPE
command-line variable first, "pentiumpro", and
no conversion is done -- the net effect is that
CPUTYPE global stays with its old value "i686",
and "make -V CPUTYPE" (which prints variables
in the global context) returns "i686".
The fix was to pass the CPUTYPE in the test above
as an environment variable instead of as a command
line variable, i.e.,
CPUTYPE=pentiumpro make -f /dev/null -V CPUTYPE
This time, CPUTYPE global is still set to "i686"
initially (by /etc/make.conf), and an envieronment
variable CPUTYPE (of a lower precedence) is set
to "pentiumpro". The .elif sees it's set to
"i686" and resets it to "pentiumpro", and so
"make -V" returns "pentiumpro".
NB: these various types of make(1) variables can
be very painful, especially when combined with
"make -V".
building the kerberos5 includes. This is not the same patch that
Bjoern A. Zeeb came up with, but the credit still goes to him for finding
the problem. Thanks!
If turned on no NIS support and related programs will be built.
Lost parts rediscovered by: Danny Braniss <danny at cs.huji.ac.il>
PR: bin/68303
No objections: des, gshapiro, nectar
Reviewed by: ru
Approved by: rwatson (mentor)
MFC after: 2 weeks
It was pointed out to me that the convention we have is to use WITH_
elsewhere in the system, eg: ports etc. This is all temporary anyway
and presumably will be inverted to a NO_LIB32 or something like it in
the future.
rates pretty high on the "hack!" scale, but it works for me. Adding
-DWANT_LIB32 to the world build command line, or 'WANT_LIB32=yes' to
/etc/make.conf will include the 32 bit libraries with the build.
I have not made this default behavior. Cross compiling this stuff is an
adventure I have not investigated.
This is still a WIP. We needed this at work so that we could install from
a readonly obj tree - lib32/build.sh wasn't up to that.
NO_BIND_DNSSEC, NO_BIND_ETC, NO_BIND_NAMED, and NO_BIND_UTILS.
2. Make creation of directories in /usr/include that are only needed
in the WITH_BIND_LIBS case conditional.
Reviewed by: ru, des
libpthread is provided by src/lib/libc_r.
Also, removed lib/bind from _generic_libs, "lib" will suffice.
Also, removed redundant lib/bind dependency on lib/libpthread
(as lib/bind is not in the _prebuild_libs, it's not needed).
Prodded by: trhodes@ reporting that des@ is on the flight
the US Senate, Canadian Parliament and Australian Senate, it was
causing some confusion. After some consultation with Mark Murray,
change this to 'without objection' since often times a plain-speaking
term is preferable to a regionally used term.
Also, clarify that this procedure is to be used when for more mundane
matters that need a sanity check, but don't need the whole, ponderous
voting proceedure that more difficult issues require. Core members
that read email in any given 48 hour period are trusted enough to know
the difference and to provide the sanity check as necessary.
Reviewed by: markm
to make(1) that causes command-line variables to be passed as
command-line variables to sub-processes that make(1) executes
broke it. By changing the type of all DESTDIR variables used
internally in Makefile.inc1, from environment to command-line
variables of the highest priority, I was able to "make world"
with success, with the command-line variable DESTDIR set.
determines which CVS tag to track when running make update. This makes
it easier to configure a box to track a particular release if it does
automated updates from a cvs repository.
in rev. 1.57. Fix this regression by making cc_tools a new-style
build-tool in Makefile.inc1. For details of what has been fixed,
please see the gnu/usr.bin/cc/cc_tools/Makefile,v 1.52 commit log.
Caught this by accidentally touching param.h while in the process
of cross-buildworld for amd64.
only, and not as a global (in /etc/make.conf) or command-line variable.
MAKEOBJDIRPREFIX has never been a global or command-line variable, and
the fact that it works in some scenarios for "make buildworld" doesn't
make it any more correct. Using it as a global or command-line variable
is error prone, discouraged, costs us lot of false build reports, etc.
This commit is aimed to fix it once and for all.
Anyone potentially objecting to this change is encouraged to read the
make(1) and make.conf(5) manpages, and the comments regarding the use
of the MAKEOBJDIRPREFIX variable in /usr/share/mk/bsd.obj.mk and
/usr/share/examples/etc/make.conf.
two -n flags. If only one -n flag is given the old behaviour
is retained (POLA). In order to make this working for installworld
change the IMAKEENV in this case so that the tools are found
(we have no temporary installation environment in this case).
Submitted by: ru (IMAKEENV part)
help some ports that depend on libradius that recently gained
the dependency on libssl. This is also how the stock OpenSSL
build would link libssl.so on FreeBSD.
Prompted by: kris
OK'ed by: markm, nectar
MS-CHAPv1 MPPE-keys).
- Added rad_demangle_mppe_key() for demangling mppe-keys (needed
for MPPE-keys).
- Added some typecasts for avoiding compiler warnings.
- Fix: better handle wrong usage of the lib (if the programmer
has not called rad_create_request() but rad_put_*(), then a
weird error message was returned).
- Added a new function for putting the Message-Authenticator.
- Verify the Message-Authenticator, if it was found inside a
response packet and silently drop the packet, if the validation
failed.
- Implicitly put the Message-Authenticator, if the EAP-Message
attribute was added.
- Added some missing defines.
Submitted by: Michael Bretterklieber
PR: 46555
revision 1.343, but it's needed for btxld(8), and this fix (along
with the --enable-64-bit-bfd configured BFD on i386) allows other
architectures to successfully cross-build the i386 world.
Tested on: alpha
because we require that a new kernel be installed prior to a new
world, and we may need some new directories to succeed.
Once MFCed, this will also help those poor souls who redundantly
``mv /modules /modules.old'' in RELENG_4 before an installkernel.
Requested by: many
MFC after: 3 days
from a 32-bit value to a 64-bit value. This commit does not actually
change anything. It merely provides instructions, scripts, and a safety
measure in Makefile.inc1 for people who want to make the change.
The real change to 64-bit time_t's on sparc64 is scheduled to happen
on March 10th, assuming that so major problems are found between now
and then by early-adopters.
Reviewed by: freebsd-sparc64
- Dropped support for standalone builds, this was only partially
supported anyway, and required so much magic in makefiles that
made life dangerous (e.g., by using the custom yacc rules).
- Got rid of .OBJDIR in makefiles -- makes building of individual
files possible again.
- Made the .x.c transformations -j safe.
- Reprogrammed LDADD to fix static build of some utilities that
was broken.
- Fixed LDFLAGS and DPADD in the WITH_OPENLDAP case -- positively
affects the contents of .depend files.
- Removed redundant .h's from SRCS, only kept those that are
generated.
- libkrb5/ INCS were bogusly installed again with libgssapi/.
- Made build-tools real tools with their own makefiles in
separate directories. This allows us to properly track
their dependencies, etc.
- Faster build, 21% less of makefile code!
Approved by: nectar
Reviewed by: markm
Silence on: arch
instead of creating them by hand and storing them in the CVS tree. Add
gensnmptree to the bootstrap tools (it is used to generated these files).
This simplifies the update procedure.
Submitted by: ru
system in a messy state *if* the user is upgrading from a system
which has no /libexec to a system which builds a DYNAMICROOT, and
if that user has set DISTDIR (as documented for ports, but it turns
out that the same variable name is used for a completely unrelated
purpose in 'make release').
There are other possible fixes for this issue, and ru@ may later
decide to commit one of those fixes. I just wanted some fix in
ASAP, and this is the fix that I have tested.
Reviewed by: bde, imp, and ru
as it was decided that our toolchain will revert to looking
for libraries in /usr/lib only.
- Make /usr/lib/libfoo.so -> /lib/libfoo.so.X symlinks absolute
so that they still work if /usr is symlinked.
- Remove stale /usr/lib/libfoo.so.X libraries during install.
Discussed with: gordon, obrien, peter
syntax. The
make buildworld
mv /usr/include /usr/include.old
make installworld
issue has been fixed a month ago in Makefile,v 1.285, and there
is no valid reason to continue to keep the wrong syntax here --
buildworld takes care of upgrading a make for you if necessary.
But if you find yourself in an environment with an old make(1)
binary that breaks on this, and this is because you attempted
to run a target other than buildworld, don't whine but try again
with -DALWAYS_CHECK_MAKE defined -- it should do the trick.
Otherwise, if you still have a problem, please report it as a
bug and attach the ``make -dl ...'' output.
Reviewed by: marcel
5.x signal code from the 4.x signal code. The split happened in
Oct 2002 and we have had 2 releases since then. A kernel older than
5.0-R cannot reasonably be called a -current kernel anymore.
This does not break upgrading from an 10 month older kernel. It just
makes it more exiting.
/usr/include/osreldate.h doesn't exist on the system. While this
could be worked around by saying something like 'make includes
OSLRELDATE=0' when this file doesn't exist, it is just as easy to
provide a fallback when the file we know we depend on doesn't exist.
While this doesn't make all targets work w/o a
/usr/include/osreldate.h, because some of the FreeBSD bootstrap tools
use this file. 'make includes' however does work.
Noticed by: peter, obrien (and likely others)
Pointy hat to: imp (for suggesting a method that depended on /usr/include)
using underscores or not, so I just randomly picked a style. I think
I have the logic correct, but if someone wants to give it a once over
that would be good.
Tim submitted a patch to fix the cross-building issues which I tested
with a tinderbox run for sparc64.
Submitted by: Tim Kientzle <kientzle@acm.org>
The latter needs to be built either if it's used as a cross-tool
(${TARGET_ARCH} != ${MACHINE_ARCH}) or if it has backward compat
issues, like e.g. lack of the AMD64 support.
4.8-stable:
Must build lib/libc before libpthread. Fix how we do this to be more
consistant with how lists are handled in the file. Also, don't bother
to prebuild libc if we're not building libpthread.
Submitted by: ru@
Reviewed by: bde@ (before ru@ submitted it)
This was the initial intent anyway, and it became clear that it is
really necessary to treat it this way, as many people happen to run
with kernel newer than the installed world.
Submitted by: imp, ru
Approved by: re (scottl)
in the SHARED=symlinks case. Symlinks to directories only work if all the
the necessary headers are in 1 directory, but the necessary headers are
scattered for at least ipfilter headers in <netinet>. This change also
avoids polluting /usr/include with non-headers; the /usr/include hierarchy
is now independent of the setting of SHARED.
Submitted by: ru (edited to fix netgraph/bluetooth/include and machine/pc)
PR: 44148
supported, it usually works for months at a time. Allow these people
to override the OSRELDATE of their installed world when things don't
match and the exact OSRELDATE matters and is different than the
kernel. Now that Makefile.inc1 depends more and more about which date
you have to optimize the pieces it builds, it may be necessary to
pessimize things if its guesses are wrong.
If OSRELDATE is already set, we won't fork the sysctl to find out what
the kernel's date is.
Developers on IRC suggested that they run mismatches all the time as
well.
Reviewed by: obrien
This allows us to use them as early as possible while building
bootstrap-, build-, and cross-tools. Some cleanups to follow.
This change resolves the gperf(1) bootstrapping issue (missing
-E option) in gnu/usr.bin/cc/cc1plus while in the cross-tools
stage when upgrading from 4.0-RELEASE.
legacy stuff (binutils) depend on this order.
For this to work, provide (and use) specialized versions
of bsd.prog.mk and bsd.lib.mk that include the standard
versions first, then augment CFLAGS, DPADD, LDADD, and
LDFLAGS as necessary, with the legacy stuff.
Tested on: 4.0-RELEASE
is because we populate these directories later, and a subsequent
-DNOCLEAN build may fail. So, we put them in
${WORLDTMP}/build/usr/{include,lib} instead and adjust Makefile.boot.
Again, this works on -stable and -current, but might break older
versions.
Submitted by: ru@
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.
