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
