2024-05-05 05:50:11 +03:00
|
|
|
$NetBSD: UPDATING,v 1.350 2024/05/05 02:50:11 riastradh Exp $
|
2018-05-02 10:34:44 +03:00
|
|
|
|
|
|
|
|
This file (UPDATING) is intended to be a brief reference to recent
|
|
|
|
|
changes that might cause problems in the build process, and a guide for
|
|
|
|
|
what to do if something doesn't work.
|
|
|
|
|
|
|
|
|
|
For a more detailed description of the recommended way to build NetBSD
|
|
|
|
|
using build.sh, see the BUILDING file.
|
|
|
|
|
|
|
|
|
|
Note that much of the advice in this UPDATING file was written before
|
|
|
|
|
build.sh existed. Nevertheless, the advice here may be useful for
|
|
|
|
|
working around specific problems with build.sh.
|
|
|
|
|
|
|
|
|
|
Sections are marked with "^^^^^". After the section on "Recent changes"
|
|
|
|
|
are several sections containing more general information.
|
|
|
|
|
|
|
|
|
|
See also: BUILDING, build.sh, Makefile.
|
|
|
|
|
|
|
|
|
|
Recent changes:
|
|
|
|
|
^^^^^^^^^^^^^^^
|
|
|
|
|
|
2024-05-05 05:50:11 +03:00
|
|
|
20240504:
|
|
|
|
|
Update builds on x86 require making the `cleandir' target in
|
|
|
|
|
lib/libm, or deleting the objdir for lib/libm.
|
|
|
|
|
|
2024-04-23 06:25:39 +03:00
|
|
|
20240423:
|
|
|
|
|
Update builds with x11 may fail after switching to Mesa 21.
|
|
|
|
|
|
2024-04-11 05:15:39 +03:00
|
|
|
20240410:
|
|
|
|
|
Update builds may require manually deleting
|
|
|
|
|
$DESTDIR/var/run/named (and, potentially,
|
|
|
|
|
$DESTDIR/var/run/lwresd) in order to avoid checkflist failure.
|
|
|
|
|
|
2024-04-11 09:20:29 +03:00
|
|
|
20240409:
|
|
|
|
|
32-bit compatibility libraries were moved into the base32
|
|
|
|
|
and debug32 sets. HTML man pages were moved into the manhtml set.
|
|
|
|
|
|
2023-08-29 01:25:49 +03:00
|
|
|
20230828:
|
|
|
|
|
If:
|
|
|
|
|
- you updated to current and ran postinstall between 20230826
|
|
|
|
|
and 20230828 inclusive, and
|
|
|
|
|
- you are not using anything outside the base system to
|
|
|
|
|
populate /etc/openssl/certs (e.g., manually adding
|
|
|
|
|
certificates or using ca-certificates or mozilla-rootcerts or
|
|
|
|
|
mozilla-rootcerts-openssl from pkgsrc),
|
|
|
|
|
delete /etc/openssl/certs and rerun postinstall or just
|
|
|
|
|
`certctl rehash'.
|
|
|
|
|
|
|
|
|
|
Otherwise, certctl(8) will think someone else has left
|
|
|
|
|
/etc/openssl/certs in the way and will avoid clobbering it on
|
|
|
|
|
upgrade from older NetBSD.
|
|
|
|
|
|
2023-07-18 19:59:57 +03:00
|
|
|
20230718:
|
|
|
|
|
build.sh will use mk.conf in the same directory as build.sh instead
|
|
|
|
|
of /etc/mk.conf, unless MAKECONF is already defined in the environment.
|
|
|
|
|
|
2023-07-19 20:49:40 +03:00
|
|
|
20230714:
|
|
|
|
|
Import of gcc 10.5 requires a clean build of at least tools/gcc
|
|
|
|
|
and external/gpl3/gcc* object directories. An update build
|
|
|
|
|
without cleaning will result in obscure failures in rare corner
|
|
|
|
|
cases.
|
|
|
|
|
|
2023-06-04 19:14:59 +03:00
|
|
|
20230604:
|
|
|
|
|
Building native kernels with the installed make(1) instead of
|
|
|
|
|
the $TOOLDIR/bin/nbmake-${arch} wrapper will fail if userland
|
|
|
|
|
has not been updated. Note that this is an unsupported build
|
|
|
|
|
configuration (but usually works if userland is -current enough).
|
2023-05-23 23:26:52 +03:00
|
|
|
|
|
|
|
|
20230523:
|
|
|
|
|
ctfmerge was fixed as macOS host tool. This may require a clean tools
|
|
|
|
|
rebuild to detect the update to tools/compat/configure.
|
|
|
|
|
|
2023-07-11 18:05:17 +03:00
|
|
|
20230515:
|
|
|
|
|
New openssl build requires removal of the crypto/external/bsd/openssl
|
2024-02-10 01:08:30 +03:00
|
|
|
and tests/crypto/libcrypto subdirectories in the ${OBJDIR} hierarchy.
|
2023-07-11 18:05:17 +03:00
|
|
|
Otherwise test results may be wrong due to wrong "golden" output
|
|
|
|
|
files being installed.
|
|
|
|
|
|
2023-03-23 10:15:08 +03:00
|
|
|
20230322:
|
|
|
|
|
Fixes for moved /lib/libisns* mean that builds will complain about
|
|
|
|
|
./usr/lib/libisns* being missing until src/lib/libisns is forced
|
|
|
|
|
to (re)install the files, including the symlinks. The simplest
|
|
|
|
|
way is to clean this subdir before building.
|
|
|
|
|
|
2023-01-16 11:49:55 +03:00
|
|
|
20230112:
|
|
|
|
|
New binutils require an updated ld.elf_so. If you are doing
|
|
|
|
|
(unsupported) in-place self builds (with the -E flag to build.sh),
|
|
|
|
|
make sure to have installed latest ld.elf_so before you rebuild
|
|
|
|
|
userland.
|
|
|
|
|
|
2022-11-17 09:40:38 +03:00
|
|
|
20221116:
|
|
|
|
|
The addition to NetBSD's version of UFS2 of support for extended
|
|
|
|
|
attributes broke backward compatibility with previous releases
|
|
|
|
|
of NetBSD, so UFS2 has been restored to being compatible with
|
|
|
|
|
previous NetBSD releases by disabling extended attributes.
|
|
|
|
|
(Note that ACLs are implemented as extended attributes, so
|
|
|
|
|
this changes disables ACLs as well.)
|
|
|
|
|
|
|
|
|
|
Support for UFS2 with extended attributes is now available in a new
|
|
|
|
|
UFS variant called UFS2ea. If you have created extended attributes
|
|
|
|
|
in an original UFS2 file system then "fsck -p" will now fail due to
|
|
|
|
|
the unexpected presence of extended attributes and "fsck -y" will
|
|
|
|
|
remove all extended attributes. If you wish to preserve extended
|
|
|
|
|
attributes rather than delete them, there is a utility to convert
|
|
|
|
|
a UFS2 file system to UFS2ea and leave extended attributes in place,
|
|
|
|
|
but this should be used with caution since it will preserve any
|
|
|
|
|
extended attributes that have been corrupted by the backward
|
|
|
|
|
incompatibility too.
|
|
|
|
|
|
|
|
|
|
If you wish to use a UFS2ea file system as your root file system,
|
|
|
|
|
then you will need to update your boot loader to a version that
|
|
|
|
|
supports UFS2ea.
|
|
|
|
|
|
|
|
|
|
For more information, see:
|
|
|
|
|
https://wiki.netbsd.org/features/UFS2ea
|
|
|
|
|
|
2022-11-12 05:20:15 +03:00
|
|
|
20221111:
|
|
|
|
|
The new libdrm import worsened the conflict issues for the
|
|
|
|
|
kdump/ktruss ioctl, and i915 now conflicts with base, and has
|
|
|
|
|
been turned off. This will cause update build issues like:
|
|
|
|
|
|
|
|
|
|
kdump-ioctl.c:12175:143: error: 'DRM_IOCTL_I915_DESTROY_HEAP'
|
|
|
|
|
undeclared here (not in a function);
|
|
|
|
|
did you mean 'DRM_IOCTL_MODE_DESTROY_DUMB'?
|
|
|
|
|
|
|
|
|
|
You'll need to clean usr.bin/ktruss, usr.bin/kdump, and rescue.
|
|
|
|
|
|
2022-09-21 17:32:26 +03:00
|
|
|
20220921:
|
|
|
|
|
Since the kernel version was bumped to 9.99.100, the bootloader
|
2022-10-08 11:21:56 +03:00
|
|
|
must be updated on x86 or EFI boot platforms in order to load
|
|
|
|
|
modules from boot.cfg(5) or interactively at the bootloader
|
|
|
|
|
prompt.
|
2022-09-21 17:32:26 +03:00
|
|
|
|
2022-10-08 11:21:56 +03:00
|
|
|
The kernel can still load modules at runtime, with modload(8)
|
|
|
|
|
or modules.conf(5), with no bootloader update. This will not
|
|
|
|
|
affect release branches because it only applies to patch
|
|
|
|
|
numbers >=100.
|
|
|
|
|
|
|
|
|
|
On x86 (i386 or amd64) with BIOS boot, this requires copying a
|
|
|
|
|
new /usr/mdec/boot to /boot. You can build this in the destdir
|
|
|
|
|
by running `$TOOLDIR/bin/nbmake-$ARCH dependall install' in
|
|
|
|
|
sys/arch/i386/stand.
|
|
|
|
|
|
|
|
|
|
On platforms with EFI boot (including x86 with EFI boot), this
|
|
|
|
|
requires copying a new /usr/mdec/boot*.efi to the EFI/BOOT/
|
|
|
|
|
directory on the EFI system partition. The boot*.efi file is:
|
|
|
|
|
|
|
|
|
|
aarch64 bootaa64.efi
|
|
|
|
|
amd64 bootx64.efi
|
|
|
|
|
arm bootarm.efi (32-bit arm)
|
|
|
|
|
i386 bootx32.efi
|
|
|
|
|
|
|
|
|
|
You can build this in the destdir by running
|
|
|
|
|
`$TOOLDIR/bin/nbmake-$ARCH dependall install' in
|
|
|
|
|
sys/stand/efiboot/boot*.
|
2022-09-21 17:32:26 +03:00
|
|
|
|
2022-08-21 10:15:28 +03:00
|
|
|
20220821:
|
|
|
|
|
Support for building extsrc/ has been deprecated.
|
|
|
|
|
EXTSRCSRCDIR and MKEXTSRC have been deprecated.
|
|
|
|
|
|
2022-07-15 08:26:08 +03:00
|
|
|
20220714:
|
|
|
|
|
Updates to xorg-server and associated drivers may cause builds to
|
|
|
|
|
fail. Cleaning both DESTDIR and the xorg build tree may be needed.
|
|
|
|
|
|
2022-06-28 11:03:49 +03:00
|
|
|
20220628:
|
|
|
|
|
Changes in the build of src/games/robots require a clean build
|
|
|
|
|
of that program.
|
|
|
|
|
|
2021-11-20 19:18:18 +03:00
|
|
|
20211116:
|
|
|
|
|
Changes in the xorg build require clean obj dirs for external/mit/xorg
|
2021-11-22 15:30:34 +03:00
|
|
|
(or a full clean/non-update build).
|
2021-11-20 19:18:18 +03:00
|
|
|
|
2021-11-14 14:16:28 +03:00
|
|
|
20211112:
|
|
|
|
|
Device tree sources were updated for evbarm. Some device nodes
|
|
|
|
|
(in particular, ld(4) devices on the ROCKPro64) will be renumbered.
|
|
|
|
|
|
2021-10-14 18:40:00 +03:00
|
|
|
20211014:
|
2021-11-14 14:16:28 +03:00
|
|
|
MKPIE default for aarch64 has changed, a clean build is required.
|
2021-10-14 18:40:00 +03:00
|
|
|
|
2021-09-18 06:05:19 +03:00
|
|
|
20210917:
|
|
|
|
|
Changed MNT_ACLS to default to POSIX1e ACLs instead of NFSv4
|
|
|
|
|
ACLs, to be compatible with FreeBSD. If you are using NFSv4 ACLs
|
|
|
|
|
and have "acls" in /etc/fstab you'll need to change it to "nfs4acls".
|
|
|
|
|
|
2021-07-12 00:58:52 +03:00
|
|
|
20210711:
|
|
|
|
|
Updated GMP sources may require cleaning in tools/gmp and/or in
|
|
|
|
|
external/lgpl3/gmp/lib, particularly if GCC itself does not build.
|
|
|
|
|
|
2021-04-17 07:08:32 +03:00
|
|
|
20210417:
|
|
|
|
|
GCC 10 was enabled for several platforms. If builds fail in either
|
|
|
|
|
tools/gcc or external/gpl/gcc, first try cleaning those objects and
|
|
|
|
|
removing the $DESTDIR/usr/include/g++ subdirectory.
|
|
|
|
|
|
2020-10-17 10:41:25 +03:00
|
|
|
20201016:
|
|
|
|
|
MIPS kernel modules have been disabled until they work. This will
|
|
|
|
|
turn up in extra files in the DESTDIR, which should be cleaned.
|
|
|
|
|
|
2020-09-26 11:02:35 +03:00
|
|
|
20200925:
|
|
|
|
|
GNU MPC and MPFR have been updated. At least MPFR needs cleaning
|
|
|
|
|
in both the tools and external dirs.
|
|
|
|
|
|
2020-09-12 11:31:39 +03:00
|
|
|
20200912:
|
|
|
|
|
GCC 9 has arrived for Arm and x86 platforms, and will be coming
|
|
|
|
|
for several more, as will binutils 2.34. Clean as required.
|
|
|
|
|
|
2020-09-07 13:19:02 +03:00
|
|
|
20200907:
|
|
|
|
|
GCC 9 is coming, and binutils has been updated for MIPS. This
|
|
|
|
|
probably requires cleaning the tools/binutils.
|
|
|
|
|
|
2020-08-12 09:48:50 +03:00
|
|
|
20200811:
|
2020-08-20 06:09:34 +03:00
|
|
|
GCC updates may require cleaning the objdir. This may occur
|
|
|
|
|
due to GCC 7.5 update, GCC 8.4 move to gcc.old, or the upcoming
|
|
|
|
|
GCC 9 upgrade.
|
2020-08-12 09:48:50 +03:00
|
|
|
|
2020-06-15 06:39:00 +03:00
|
|
|
20200614:
|
2020-06-16 00:52:03 +03:00
|
|
|
blacklist* has been renamed to blocklist*. postinstall(8)
|
2022-09-22 01:01:56 +03:00
|
|
|
should handle the migration.
|
2020-06-15 06:39:00 +03:00
|
|
|
|
2020-06-01 17:46:04 +03:00
|
|
|
20200601:
|
|
|
|
|
Due to a mistake in LIBISPRIVATE handling, .so libraries were
|
|
|
|
|
created in the build directories and need cleaning.
|
|
|
|
|
|
2020-03-12 00:07:40 +03:00
|
|
|
20200311:
|
|
|
|
|
GCC 8 ports will need cleaning in src/tools/gcc and
|
|
|
|
|
src/external/gpl3/gcc due to GCC 8.4 update.
|
|
|
|
|
|
2019-11-18 18:42:26 +03:00
|
|
|
20191118:
|
|
|
|
|
More architectures were switched to gcc8:
|
|
|
|
|
i386, ia64 powerpc64, sparc, sparc64, arm
|
|
|
|
|
The same comments as in 20191022 apply.
|
|
|
|
|
|
2019-11-13 12:59:02 +03:00
|
|
|
20191112:
|
|
|
|
|
The LLVM update requires a clean rebuild for all architectures using
|
|
|
|
|
LLVM during the tools build phase (i386, amd64, aarch64).
|
|
|
|
|
|
2019-10-23 19:26:42 +03:00
|
|
|
20191022:
|
|
|
|
|
Ports amd64 and aarch64 switched to GCC 8.3 by default.
|
|
|
|
|
In-place ("expert mode", build.sh -E) builds are not supported
|
|
|
|
|
when going from a GCC 7 userland to GCC 8. Do a regular
|
|
|
|
|
build to a different DESTDIR (or preferably: build.sh -U) at least
|
2019-11-18 18:42:26 +03:00
|
|
|
once and install sets, or download comp.{tar.xz,tgz} from the
|
2019-10-23 19:26:42 +03:00
|
|
|
daily builds and install that before doing the next in-place build.
|
|
|
|
|
|
2019-10-01 12:36:56 +03:00
|
|
|
20191001:
|
|
|
|
|
GCC 8.3 was imported. Builds of src/tools/gcc may fail if
|
|
|
|
|
old builds with GCC 7 output now uses GCC 8. Clean this
|
|
|
|
|
directory, and also clean src/external/gpl3/gcc.
|
|
|
|
|
|
2019-09-03 18:38:52 +03:00
|
|
|
20190903:
|
2019-11-18 18:42:26 +03:00
|
|
|
Files with names that coincide with existing files' names on
|
2019-09-03 18:38:52 +03:00
|
|
|
case-insensitive file systems were inadvertently committed, for
|
|
|
|
|
radeon GPU firmware. We cannot mark these as obsolete for
|
|
|
|
|
postinstall to fix, so if you updated src since 2019-08-26, and
|
|
|
|
|
ran build.sh distribution or ran build.sh release, you must
|
|
|
|
|
manually delete the following files in your DESTDIR (which is
|
|
|
|
|
usually $OBJDIR/destir.$ARCH), or from / if you have installed
|
|
|
|
|
them:
|
|
|
|
|
|
|
|
|
|
/libdata/firmware/radeon/bonaire_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_me.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_mec.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_sdma.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_smc.bin
|
|
|
|
|
/libdata/firmware/radeon/bonaire_uvd.bin
|
|
|
|
|
/libdata/firmware/radeon/hainan_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/hainan_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/hainan_me.bin
|
|
|
|
|
/libdata/firmware/radeon/hainan_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/hainan_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/hainan_smc.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_me.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_mec.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_sdma.bin
|
|
|
|
|
/libdata/firmware/radeon/hawaii_smc.bin
|
|
|
|
|
/libdata/firmware/radeon/kabini_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/kabini_me.bin
|
|
|
|
|
/libdata/firmware/radeon/kabini_mec.bin
|
|
|
|
|
/libdata/firmware/radeon/kabini_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/kabini_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/kabini_sdma.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_me.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_mec.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_mec2.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/kaveri_sdma.bin
|
|
|
|
|
/libdata/firmware/radeon/mullins_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/mullins_me.bin
|
|
|
|
|
/libdata/firmware/radeon/mullins_mec.bin
|
|
|
|
|
/libdata/firmware/radeon/mullins_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/mullins_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/mullins_sdma.bin
|
|
|
|
|
/libdata/firmware/radeon/oland_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/oland_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/oland_me.bin
|
|
|
|
|
/libdata/firmware/radeon/oland_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/oland_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/oland_smc.bin
|
|
|
|
|
/libdata/firmware/radeon/pitcairn_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/pitcairn_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/pitcairn_me.bin
|
|
|
|
|
/libdata/firmware/radeon/pitcairn_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/pitcairn_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/pitcairn_smc.bin
|
|
|
|
|
/libdata/firmware/radeon/tahiti_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/tahiti_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/tahiti_me.bin
|
|
|
|
|
/libdata/firmware/radeon/tahiti_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/tahiti_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/tahiti_smc.bin
|
|
|
|
|
/libdata/firmware/radeon/verde_ce.bin
|
|
|
|
|
/libdata/firmware/radeon/verde_mc.bin
|
|
|
|
|
/libdata/firmware/radeon/verde_me.bin
|
|
|
|
|
/libdata/firmware/radeon/verde_pfp.bin
|
|
|
|
|
/libdata/firmware/radeon/verde_rlc.bin
|
|
|
|
|
/libdata/firmware/radeon/verde_smc.bin
|
|
|
|
|
|
|
|
|
|
We will re-import these radeon firmware images another way
|
|
|
|
|
later.
|
|
|
|
|
|
2019-07-27 10:55:18 +03:00
|
|
|
20190727:
|
|
|
|
|
The uefi bootloader has gained tftp support and needs a clean
|
|
|
|
|
build. If you do update builds, manually clean its object
|
|
|
|
|
directory by something like:
|
|
|
|
|
cd sys/arch/i386/stand/efiboot && make clean
|
|
|
|
|
|
2019-07-23 09:35:40 +03:00
|
|
|
20190723:
|
2023-09-24 19:33:41 +03:00
|
|
|
The jemalloc allocator in libc is now built without extended
|
2019-07-23 09:35:40 +03:00
|
|
|
debugging (for performance reasons). In update builds make sure
|
2021-12-08 00:37:36 +03:00
|
|
|
to rebuild it completely, by removing all affected object files,
|
2019-07-23 09:35:40 +03:00
|
|
|
including compat builds, something like:
|
|
|
|
|
cd /usr/obj && find . -type d -name jemalloc|xargs rm -rf
|
|
|
|
|
|
2019-02-08 12:57:01 +03:00
|
|
|
20190207:
|
|
|
|
|
GCC 7 switched for many ports. Update builds are likely to fail.
|
|
|
|
|
|
2018-05-02 10:34:44 +03:00
|
|
|
Hints for a more successful build:
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
Use build.sh, but do not use its "expert mode":
|
|
|
|
|
This will automatically build the tools in the
|
|
|
|
|
correct order, and it will keep the tools and the
|
|
|
|
|
new build products from interfering with the running
|
|
|
|
|
system. This will allow you to ignore most of the
|
|
|
|
|
other advice in this file.
|
|
|
|
|
Build a new kernel first:
|
|
|
|
|
This makes sure that any new system calls or features
|
|
|
|
|
expected by the new userland will be present. This
|
|
|
|
|
helps to avoid critical errors when upgrading.
|
|
|
|
|
Use object directories:
|
|
|
|
|
This helps to keep stale object
|
|
|
|
|
files from polluting the build if a Makefile "forgets"
|
|
|
|
|
about one. It also makes it easier to clean up after
|
|
|
|
|
a build. It's also necessary if you want to use the
|
|
|
|
|
same source tree for multiple machines.
|
|
|
|
|
To use object directories with build.sh:
|
|
|
|
|
a) invoke build.sh with the "-M" or "-O" options.
|
|
|
|
|
To use object directories without using build.sh:
|
|
|
|
|
a) cd /usr/src ; make cleandir
|
|
|
|
|
b) Add "OBJMACHINE=yes" to /etc/mk.conf
|
|
|
|
|
c) Add "MKOBJDIRS=yes" to /etc/mk.conf
|
|
|
|
|
d) cd /usr/src ; make build
|
|
|
|
|
Note that running "make obj" in a directory will create
|
|
|
|
|
in obj.$MACHINE directory.
|
|
|
|
|
Build to a DESTDIR:
|
|
|
|
|
This helps to keep old installed files (especially libraries)
|
|
|
|
|
from interfering with the new build.
|
|
|
|
|
To build to a DESTDIR with build.sh, use the "-D" option.
|
|
|
|
|
To build to a DESTDIR without using build.sh, set the DESTDIR
|
|
|
|
|
environment variable before running make build. It should be
|
|
|
|
|
set to the pathname of an initially empty directory.
|
|
|
|
|
Problems: if you do not use build.sh, you might need to
|
|
|
|
|
update critical utilities without using DESTDIR since
|
|
|
|
|
nothing is executed from what is installed in DESTDIR.
|
|
|
|
|
(See critical utils, below.)
|
|
|
|
|
Build often:
|
|
|
|
|
This keeps critical utilities current enough to not choke
|
|
|
|
|
on any other part of the source tree that depends on up to
|
|
|
|
|
date functionality. If you use build.sh, you should not have
|
|
|
|
|
this problem.
|
|
|
|
|
|
|
|
|
|
What to do if things don't work:
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
When things don't work there are usually a few things that commonly
|
|
|
|
|
should be done.
|
|
|
|
|
1) make includes
|
|
|
|
|
This should be done automatically by make build.
|
|
|
|
|
2) cd share/mk && make install
|
|
|
|
|
Again, automatically done by make build.
|
|
|
|
|
|
|
|
|
|
Failsafe rebuild of a small part of the tree:
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
To make sure you rebuild something correctly you want to do
|
|
|
|
|
something like the following:
|
|
|
|
|
1) Make sure the includes and .mk files are up to date.
|
|
|
|
|
2) Make sure any program used to build the particular
|
|
|
|
|
utility is up to date. (yacc, lex, etc...)
|
|
|
|
|
3) cd ...path/to/util...
|
|
|
|
|
make cleandir
|
|
|
|
|
rm ...all obj directories...
|
|
|
|
|
make cleandir # yes, again
|
|
|
|
|
make obj
|
|
|
|
|
make depend && make
|
|
|
|
|
|
|
|
|
|
Failsafe rebuild of the entire tree:
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
If you really want to make sure the source tree is clean and
|
|
|
|
|
ready for a build try the following. Note that sourcing /etc/mk.conf
|
|
|
|
|
(a make(1) Makefile) in this manner is not right, and will not work
|
|
|
|
|
for anyone who uses any make(1) features in /etc/mk.conf.
|
|
|
|
|
|
|
|
|
|
---cut here---
|
|
|
|
|
#!/bin/sh
|
|
|
|
|
. /etc/mk.conf
|
|
|
|
|
|
|
|
|
|
if [ -z $NETBSDSRCDIR ] ; then
|
|
|
|
|
NETBSDSRCDIR=/usr/src
|
|
|
|
|
fi
|
|
|
|
|
if [ \! -d $NETBSDSRCDIR ] ; then
|
|
|
|
|
echo Unable to find sources
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
|
|
|
|
find $NETBSDSRCDIR -name \*.o -o -name obj.\* -o -name obj -exec rm \{\} \;
|
|
|
|
|
|
|
|
|
|
if [ -z $BSDOBJDIR ] ; then
|
|
|
|
|
BSDOBJDIR=/usr/obj
|
|
|
|
|
fi
|
|
|
|
|
if [ -d $BSDOBJDIR ] ; then
|
|
|
|
|
rm -rf $BSDOBJDIR
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
cd $NETBSDSRCDIR && make cleandir
|
|
|
|
|
|
|
|
|
|
---cut here---
|
|
|
|
|
|
|
|
|
|
Critical utilities:
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
usr.bin/make
|
|
|
|
|
usr.bin/yacc
|
|
|
|
|
usr.bin/lex
|
|
|
|
|
usr.bin/xlint
|
|
|
|
|
usr.bin/config
|
|
|
|
|
|
|
|
|
|
Other problems and possible solutions:
|
|
|
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
|
Symptom:Complaints involving a Makefile.
|
|
|
|
|
Fix: Rebuild usr.bin/make:
|
|
|
|
|
cd usr.bin/make && make && make install
|
|
|
|
|
Or, a failsafe method if that doesn't work:
|
2024-04-20 17:06:47 +03:00
|
|
|
cd usr.bin/make && cc -DMAKE_NATIVE *.c -I. -o make \
|
|
|
|
|
&& install make /usr/bin
|
2018-05-02 10:34:44 +03:00
|
|
|
|
|
|
|
|
Fix: Make sure .mk files are up to date.
|
|
|
|
|
cd share/mk && make install
|
|
|
|
|
|
|
|
|
|
Symptom:Kernel `config' fails to configure any kernel, including GENERIC.
|
|
|
|
|
Fix: Rebuild usr.bin/config
|
|
|
|
|
|
|
|
|
|
Symptom:Obsolete intermediate files are used during compilation
|
|
|
|
|
Fix: Try the following sequence of commands in the directory in question.
|
|
|
|
|
make cleandir; rm `make print-objdir`; make cleandir; make obj
|
|
|
|
|
(If you built the tree without "make obj" in the past, obsolete files
|
|
|
|
|
may remain. The command tries to clean everything up)
|
|
|
|
|
|
|
|
|
|
Symptom:.../sysinst/run.c:xx: warning: initialization from incompatible
|
|
|
|
|
pointer type
|
|
|
|
|
Fix: Rebuild and install usr.bin/menuc
|
|
|
|
|
|
|
|
|
|
Symptom:mklocale not found during build in share/locale/ctype
|
|
|
|
|
Fix: Build and install usr.bin/mklocale
|
|
|
|
|
|
|
|
|
|
Symptom:undefined reference to `__assert13' or `__unsetenv13'
|
|
|
|
|
Fix: Rebuild and install lib/libc
|
|
|
|
|
|
|
|
|
|
Symptom:usr.bin/config fails to build.
|
|
|
|
|
Fix: Try building with -DMAKE_BOOTSTRAP added to CFLAGS in Makefile.
|
|
|
|
|
|
|
|
|
|
Symptom:undefined reference to `getprogname' or `setprogname'
|
|
|
|
|
Fix: Rebuild and install lib/libc
|
|
|
|
|
|
|
|
|
|
Symptom:Update build fails in src/tools/gcc complaining that a variable
|
|
|
|
|
(e.g. CPPFLAGS) has changed since the previous run.
|
|
|
|
|
Fix: Run "nbmake-${ARCH} clean" in src/tools/gcc or do a clean build.
|
|
|
|
|
|
|
|
|
|
Symptom:cvs [update aborted]: cannot open directory /cvsroot/src/...:
|
|
|
|
|
No such file or directory.
|
|
|
|
|
Cause: If a directory is created by mistake, then it is sometimes
|
|
|
|
|
deleted from the CVS repository using administrative commands
|
|
|
|
|
that bypass the normal cvs access controls. If your cvs working tree
|
|
|
|
|
contains references to a directory that has been deleted on the
|
|
|
|
|
server in this way, then "cvs update" reports this error.
|
|
|
|
|
Fix: Recursively delete the affected directory from your working tree
|
|
|
|
|
and try the update again.
|
