1*e78994e2Sriastradh$NetBSD: UPDATING,v 1.374 2024/11/23 14:51:58 riastradh Exp $ 2f1de59e0Spgoyette 3f1de59e0SpgoyetteThis file (UPDATING) is intended to be a brief reference to recent 4f1de59e0Spgoyettechanges that might cause problems in the build process, and a guide for 5f1de59e0Spgoyettewhat to do if something doesn't work. 6f1de59e0Spgoyette 7f1de59e0SpgoyetteFor a more detailed description of the recommended way to build NetBSD 8f1de59e0Spgoyetteusing build.sh, see the BUILDING file. 9f1de59e0Spgoyette 10f1de59e0SpgoyetteNote that much of the advice in this UPDATING file was written before 11f1de59e0Spgoyettebuild.sh existed. Nevertheless, the advice here may be useful for 12f1de59e0Spgoyetteworking around specific problems with build.sh. 13f1de59e0Spgoyette 14f1de59e0SpgoyetteSections are marked with "^^^^^". After the section on "Recent changes" 15f1de59e0Spgoyetteare several sections containing more general information. 16f1de59e0Spgoyette 17f1de59e0SpgoyetteSee also: BUILDING, build.sh, Makefile. 18f1de59e0Spgoyette 19f1de59e0SpgoyetteRecent changes: 20f1de59e0Spgoyette^^^^^^^^^^^^^^^ 21f1de59e0Spgoyette 22b24ccd2cSriastradh20241122: 23b1adbe07Sriastradh Changes to various libraries' build options require cleaning 24b1adbe07Sriastradh their objdirs in update builds: 2574dd08e1Sriastradh 269d5d4290Sriastradh cd external/bsd/file/lib && $TOOLDIR/bin/nbmake-$ARCH clean 27efaaa90dSriastradh cd external/bsd/libarchive/lib && $TOOLDIR/bin/nbmake-$ARCH clean 28efaaa90dSriastradh cd external/public-domain/xz/lib && $TOOLDIR/bin/nbmake-$ARCH clean 2974dd08e1Sriastradh 30*e78994e2Sriastradh Also, for architectures with MKCOMPAT, it is necessary to clean 31*e78994e2Sriastradh the compat objdirs too. The easiest way is: 32*e78994e2Sriastradh 33*e78994e2Sriastradh rm -rf OBJDIR/compat/*/*/external/bsd/file/lib 34*e78994e2Sriastradh rm -rf OBJDIR/compat/*/*/external/bsd/libarchive/lib 35*e78994e2Sriastradh rm -rf OBJDIR/compat/*/*/external/public-domain/xz/lib 36*e78994e2Sriastradh 37b24ccd2cSriastradh Changes to bsd.lib.mk to improve detecting differences in 38b24ccd2cSriastradh shared library symbol exports may cause some .actsym files in 39b24ccd2cSriastradh the objdir to become stale in update builds. 40b24ccd2cSriastradh 41b24ccd2cSriastradh To work around this, delete all files matching `*.actsym' in 42b24ccd2cSriastradh the objdir. For example: 43b24ccd2cSriastradh 44b24ccd2cSriastradh find OBJDIR -name '*.actsym' -type f -print0 | xargs -0 rm 45b24ccd2cSriastradh 465c320c97Smartin20241104: 475c320c97Smartin Changes around the integration of the zstd compression 485c320c97Smartin library may require manual deletion of some object directories 49d9eff91dSriastradh if you update from a build from a few days ago: 50d9eff91dSriastradh rm -rf DESTDIR/usr/lib/*/libarchive* 51d9eff91dSriastradh rm -rf DESTDIR/usr/lib/*/libmagic* 52d9eff91dSriastradh rm -rf DESTDIR/usr/lib/*/libzstd* 53d9eff91dSriastradh rm -rf DESTDIR/usr/lib/libarchive* 54d9eff91dSriastradh rm -rf DESTDIR/usr/lib/libmagic* 55d9eff91dSriastradh rm -rf DESTDIR/usr/lib/libzstd* 56d9eff91dSriastradh rm -rf OBJDIR/compat/*/*/external/bsd/file/ 57d9eff91dSriastradh rm -rf OBJDIR/compat/*/*/external/bsd/libarchive/ 58d9eff91dSriastradh rm -rf OBJDIR/compat/*/*/external/bsd/zstd/ 59d9eff91dSriastradh rm -rf OBJDIR/external/bsd/file/ 60d9eff91dSriastradh rm -rf OBJDIR/external/bsd/libarchive/ 61d9eff91dSriastradh rm -rf OBJDIR/external/bsd/zstd/ 62d9eff91dSriastradh rm -rf OBJDIR/external/gpl3/gcc/ 63d9eff91dSriastradh rm -rf OBJDIR/tools/gcc/ 645c320c97Smartin 65de422bfaSwiz20240926: 66de422bfaSwiz Building -current when running on amd64 from about 20240924 67de422bfaSwiz to about 20240926 will not work due to a "malloc_np.h" 68de422bfaSwiz error. Please downgrade to a version from 20240924 or older, 69de422bfaSwiz or upgrade to a newer version e.g. using a binary release from 70de422bfaSwiz the NetBSD build servers. 71de422bfaSwiz 7242832251Smartin20240923: 7342832251Smartin Update builds will require cleaning the object directories for 74135c3fd7Smartin jemalloc (like: "rm -rf $OBJ/external/bsd/jemalloc*") and the 75135c3fd7Smartin libc dependency files (like: "rm $OBJ/lib/libc/jemalloc.*"). 76135c3fd7Smartin On architectures with COMPAT libs, those also have to be cleaned, 77135c3fd7Smartin e.g. on sparc64: "rm -rf $OBJ/compat/sparc64/sparc/external/bsd/jemalloc*" 78135c3fd7Smartin and "rm $OBJ/compat/sparc64/sparc/lib/libc/jemalloc.*". 7942832251Smartin 80c9aabab2Schristos20240817: 81c9aabab2Schristos Update builds will require cleaning in src/external/historical/nawk/bin 82c9aabab2Schristos in order to remove the awk binary since now there is a subdirectory 83c9aabab2Schristos called awk. 8442832251Smartin 8572e0215bSmartin20240812: 8672e0215bSmartin Update builds will require removing the tools objdir for gdb 8772e0215bSmartin if building with MKCROSSGDB=yes. All architectures use gdb.old 8872e0215bSmartin now. 8972e0215bSmartin 90143b2b09Smartin20240630: 91dce29051Smartin Update builds will require removing the tools objdir for binutils 92dce29051Smartin (as most architectures should use binutils.old now). 93dce29051Smartin 942436a61bSkre20240610: 952436a61bSkre Update builds are likely to require removing the objdir for 962436a61bSkre distrib/<arch>/cdroms - or at least references to libarchive 972436a61bSkre from within there after the recent libarchive update. 982436a61bSkre 998f27842eSriastradh20240504: 1008f27842eSriastradh Update builds on x86 require making the `cleandir' target in 1018f27842eSriastradh lib/libm, or deleting the objdir for lib/libm. 1028f27842eSriastradh 1038a12906dSmaya20240423: 1048a12906dSmaya Update builds with x11 may fail after switching to Mesa 21. 1058a12906dSmaya 106b73702cbSriastradh20240410: 107b73702cbSriastradh Update builds may require manually deleting 108b73702cbSriastradh $DESTDIR/var/run/named (and, potentially, 109b73702cbSriastradh $DESTDIR/var/run/lwresd) in order to avoid checkflist failure. 110b73702cbSriastradh 111316aa9d9Snia20240409: 112316aa9d9Snia 32-bit compatibility libraries were moved into the base32 113316aa9d9Snia and debug32 sets. HTML man pages were moved into the manhtml set. 114316aa9d9Snia 1151cac5d57Sriastradh20230828: 1161cac5d57Sriastradh If: 1171cac5d57Sriastradh - you updated to current and ran postinstall between 20230826 1181cac5d57Sriastradh and 20230828 inclusive, and 1191cac5d57Sriastradh - you are not using anything outside the base system to 1201cac5d57Sriastradh populate /etc/openssl/certs (e.g., manually adding 1211cac5d57Sriastradh certificates or using ca-certificates or mozilla-rootcerts or 1221cac5d57Sriastradh mozilla-rootcerts-openssl from pkgsrc), 1231cac5d57Sriastradh delete /etc/openssl/certs and rerun postinstall or just 1241cac5d57Sriastradh `certctl rehash'. 1251cac5d57Sriastradh 1261cac5d57Sriastradh Otherwise, certctl(8) will think someone else has left 1271cac5d57Sriastradh /etc/openssl/certs in the way and will avoid clobbering it on 1281cac5d57Sriastradh upgrade from older NetBSD. 1291cac5d57Sriastradh 1303cb563b3Slukem20230718: 1313cb563b3Slukem build.sh will use mk.conf in the same directory as build.sh instead 1323cb563b3Slukem of /etc/mk.conf, unless MAKECONF is already defined in the environment. 1333cb563b3Slukem 134ce01b03dSmartin20230714: 135ce01b03dSmartin Import of gcc 10.5 requires a clean build of at least tools/gcc 136ce01b03dSmartin and external/gpl3/gcc* object directories. An update build 137ce01b03dSmartin without cleaning will result in obscure failures in rare corner 138ce01b03dSmartin cases. 139ce01b03dSmartin 1401479973bSmartin20230604: 1411479973bSmartin Building native kernels with the installed make(1) instead of 1421479973bSmartin the $TOOLDIR/bin/nbmake-${arch} wrapper will fail if userland 1431479973bSmartin has not been updated. Note that this is an unsupported build 1441479973bSmartin configuration (but usually works if userland is -current enough). 1459ba055b4Slukem 1469ba055b4Slukem20230523: 1479ba055b4Slukem ctfmerge was fixed as macOS host tool. This may require a clean tools 1489ba055b4Slukem rebuild to detect the update to tools/compat/configure. 1499ba055b4Slukem 150a2f264d2Smartin20230515: 151a2f264d2Smartin New openssl build requires removal of the crypto/external/bsd/openssl 152100a3398Sandvar and tests/crypto/libcrypto subdirectories in the ${OBJDIR} hierarchy. 153a2f264d2Smartin Otherwise test results may be wrong due to wrong "golden" output 154a2f264d2Smartin files being installed. 155a2f264d2Smartin 15679cbfccbSmrg20230322: 15779cbfccbSmrg Fixes for moved /lib/libisns* mean that builds will complain about 15879cbfccbSmrg ./usr/lib/libisns* being missing until src/lib/libisns is forced 15979cbfccbSmrg to (re)install the files, including the symlinks. The simplest 16079cbfccbSmrg way is to clean this subdir before building. 16179cbfccbSmrg 162021fe6e8Smartin20230112: 163021fe6e8Smartin New binutils require an updated ld.elf_so. If you are doing 164021fe6e8Smartin (unsupported) in-place self builds (with the -E flag to build.sh), 165021fe6e8Smartin make sure to have installed latest ld.elf_so before you rebuild 166021fe6e8Smartin userland. 167021fe6e8Smartin 16887ba0e2aSchs20221116: 16987ba0e2aSchs The addition to NetBSD's version of UFS2 of support for extended 17087ba0e2aSchs attributes broke backward compatibility with previous releases 17187ba0e2aSchs of NetBSD, so UFS2 has been restored to being compatible with 17287ba0e2aSchs previous NetBSD releases by disabling extended attributes. 17387ba0e2aSchs (Note that ACLs are implemented as extended attributes, so 17487ba0e2aSchs this changes disables ACLs as well.) 17587ba0e2aSchs 17687ba0e2aSchs Support for UFS2 with extended attributes is now available in a new 17787ba0e2aSchs UFS variant called UFS2ea. If you have created extended attributes 17887ba0e2aSchs in an original UFS2 file system then "fsck -p" will now fail due to 17987ba0e2aSchs the unexpected presence of extended attributes and "fsck -y" will 18087ba0e2aSchs remove all extended attributes. If you wish to preserve extended 18187ba0e2aSchs attributes rather than delete them, there is a utility to convert 18287ba0e2aSchs a UFS2 file system to UFS2ea and leave extended attributes in place, 18387ba0e2aSchs but this should be used with caution since it will preserve any 18487ba0e2aSchs extended attributes that have been corrupted by the backward 18587ba0e2aSchs incompatibility too. 18687ba0e2aSchs 18787ba0e2aSchs If you wish to use a UFS2ea file system as your root file system, 18887ba0e2aSchs then you will need to update your boot loader to a version that 18987ba0e2aSchs supports UFS2ea. 19087ba0e2aSchs 19187ba0e2aSchs For more information, see: 19287ba0e2aSchs https://wiki.netbsd.org/features/UFS2ea 19387ba0e2aSchs 1940cb9ef91Smrg20221111: 1950cb9ef91Smrg The new libdrm import worsened the conflict issues for the 1960cb9ef91Smrg kdump/ktruss ioctl, and i915 now conflicts with base, and has 1970cb9ef91Smrg been turned off. This will cause update build issues like: 1980cb9ef91Smrg 1990cb9ef91Smrg kdump-ioctl.c:12175:143: error: 'DRM_IOCTL_I915_DESTROY_HEAP' 2000cb9ef91Smrg undeclared here (not in a function); 2010cb9ef91Smrg did you mean 'DRM_IOCTL_MODE_DESTROY_DUMB'? 2020cb9ef91Smrg 2030cb9ef91Smrg You'll need to clean usr.bin/ktruss, usr.bin/kdump, and rescue. 2040cb9ef91Smrg 205fc013a7cSriastradh20220921: 206fc013a7cSriastradh Since the kernel version was bumped to 9.99.100, the bootloader 20774529798Sriastradh must be updated on x86 or EFI boot platforms in order to load 20874529798Sriastradh modules from boot.cfg(5) or interactively at the bootloader 20974529798Sriastradh prompt. 210fc013a7cSriastradh 21174529798Sriastradh The kernel can still load modules at runtime, with modload(8) 21274529798Sriastradh or modules.conf(5), with no bootloader update. This will not 21374529798Sriastradh affect release branches because it only applies to patch 21474529798Sriastradh numbers >=100. 21574529798Sriastradh 21674529798Sriastradh On x86 (i386 or amd64) with BIOS boot, this requires copying a 21774529798Sriastradh new /usr/mdec/boot to /boot. You can build this in the destdir 21874529798Sriastradh by running `$TOOLDIR/bin/nbmake-$ARCH dependall install' in 21974529798Sriastradh sys/arch/i386/stand. 22074529798Sriastradh 22174529798Sriastradh On platforms with EFI boot (including x86 with EFI boot), this 22274529798Sriastradh requires copying a new /usr/mdec/boot*.efi to the EFI/BOOT/ 22374529798Sriastradh directory on the EFI system partition. The boot*.efi file is: 22474529798Sriastradh 22574529798Sriastradh aarch64 bootaa64.efi 22674529798Sriastradh amd64 bootx64.efi 22774529798Sriastradh arm bootarm.efi (32-bit arm) 22874529798Sriastradh i386 bootx32.efi 22974529798Sriastradh 23074529798Sriastradh You can build this in the destdir by running 23174529798Sriastradh `$TOOLDIR/bin/nbmake-$ARCH dependall install' in 23274529798Sriastradh sys/stand/efiboot/boot*. 233fc013a7cSriastradh 234efdcdb3aSlukem20220821: 235efdcdb3aSlukem Support for building extsrc/ has been deprecated. 236efdcdb3aSlukem EXTSRCSRCDIR and MKEXTSRC have been deprecated. 237efdcdb3aSlukem 238a1f26e6dSmrg20220714: 239a1f26e6dSmrg Updates to xorg-server and associated drivers may cause builds to 240a1f26e6dSmrg fail. Cleaning both DESTDIR and the xorg build tree may be needed. 241a1f26e6dSmrg 242ca30fa10Smartin20220628: 243ca30fa10Smartin Changes in the build of src/games/robots require a clean build 244ca30fa10Smartin of that program. 245ca30fa10Smartin 246775f6854Smartin20211116: 247775f6854Smartin Changes in the xorg build require clean obj dirs for external/mit/xorg 24845639db1Smartin (or a full clean/non-update build). 249775f6854Smartin 250d52af69fSnia20211112: 251d52af69fSnia Device tree sources were updated for evbarm. Some device nodes 252d52af69fSnia (in particular, ld(4) devices on the ROCKPro64) will be renumbered. 253d52af69fSnia 254d8f1880cSmartin20211014: 255d52af69fSnia MKPIE default for aarch64 has changed, a clean build is required. 256d8f1880cSmartin 257292aad75Schristos20210917: 258292aad75Schristos Changed MNT_ACLS to default to POSIX1e ACLs instead of NFSv4 259292aad75Schristos ACLs, to be compatible with FreeBSD. If you are using NFSv4 ACLs 260292aad75Schristos and have "acls" in /etc/fstab you'll need to change it to "nfs4acls". 261292aad75Schristos 2620e3d1d88Smrg20210711: 2630e3d1d88Smrg Updated GMP sources may require cleaning in tools/gmp and/or in 2640e3d1d88Smrg external/lgpl3/gmp/lib, particularly if GCC itself does not build. 2650e3d1d88Smrg 2668ee87df8Smrg20210417: 2678ee87df8Smrg GCC 10 was enabled for several platforms. If builds fail in either 26815388449Sgutteridge tools/gcc or external/gpl3/gcc, first try cleaning those objects and 2698ee87df8Smrg removing the $DESTDIR/usr/include/g++ subdirectory. 2708ee87df8Smrg 2710a203a0eSmrg20201016: 2720a203a0eSmrg MIPS kernel modules have been disabled until they work. This will 2730a203a0eSmrg turn up in extra files in the DESTDIR, which should be cleaned. 2740a203a0eSmrg 27512d8f9c5Smrg20200925: 27612d8f9c5Smrg GNU MPC and MPFR have been updated. At least MPFR needs cleaning 27712d8f9c5Smrg in both the tools and external dirs. 27812d8f9c5Smrg 279a1c8c273Smrg20200912: 280a1c8c273Smrg GCC 9 has arrived for Arm and x86 platforms, and will be coming 281a1c8c273Smrg for several more, as will binutils 2.34. Clean as required. 282a1c8c273Smrg 283210197e4Smrg20200907: 284210197e4Smrg GCC 9 is coming, and binutils has been updated for MIPS. This 285210197e4Smrg probably requires cleaning the tools/binutils. 286210197e4Smrg 2872d54d631Smrg20200811: 2881d16bf73Smrg GCC updates may require cleaning the objdir. This may occur 2891d16bf73Smrg due to GCC 7.5 update, GCC 8.4 move to gcc.old, or the upcoming 2901d16bf73Smrg GCC 9 upgrade. 2912d54d631Smrg 2929cd8f587Schristos20200614: 2936d0b1957Schristos blacklist* has been renamed to blocklist*. postinstall(8) 2944a266d15Sgutteridge should handle the migration. 2959cd8f587Schristos 296bc540875Schristos20200601: 297bc540875Schristos Due to a mistake in LIBISPRIVATE handling, .so libraries were 298bc540875Schristos created in the build directories and need cleaning. 299bc540875Schristos 300e913553bSmrg20200311: 301e913553bSmrg GCC 8 ports will need cleaning in src/tools/gcc and 302e913553bSmrg src/external/gpl3/gcc due to GCC 8.4 update. 303e913553bSmrg 304fa876f5dSchristos20191118: 305fa876f5dSchristos More architectures were switched to gcc8: 306fa876f5dSchristos i386, ia64 powerpc64, sparc, sparc64, arm 307fa876f5dSchristos The same comments as in 20191022 apply. 308fa876f5dSchristos 309c2a6468fSmartin20191112: 310c2a6468fSmartin The LLVM update requires a clean rebuild for all architectures using 311c2a6468fSmartin LLVM during the tools build phase (i386, amd64, aarch64). 312c2a6468fSmartin 313e899ddb1Smartin20191022: 314e899ddb1Smartin Ports amd64 and aarch64 switched to GCC 8.3 by default. 315e899ddb1Smartin In-place ("expert mode", build.sh -E) builds are not supported 316e899ddb1Smartin when going from a GCC 7 userland to GCC 8. Do a regular 317e899ddb1Smartin build to a different DESTDIR (or preferably: build.sh -U) at least 318fa876f5dSchristos once and install sets, or download comp.{tar.xz,tgz} from the 319e899ddb1Smartin daily builds and install that before doing the next in-place build. 320e899ddb1Smartin 321e9ed1017Smrg20191001: 322e9ed1017Smrg GCC 8.3 was imported. Builds of src/tools/gcc may fail if 323e9ed1017Smrg old builds with GCC 7 output now uses GCC 8. Clean this 324e9ed1017Smrg directory, and also clean src/external/gpl3/gcc. 325e9ed1017Smrg 326b371a198Sriastradh20190903: 327fa876f5dSchristos Files with names that coincide with existing files' names on 328b371a198Sriastradh case-insensitive file systems were inadvertently committed, for 329b371a198Sriastradh radeon GPU firmware. We cannot mark these as obsolete for 330b371a198Sriastradh postinstall to fix, so if you updated src since 2019-08-26, and 331b371a198Sriastradh ran build.sh distribution or ran build.sh release, you must 332b371a198Sriastradh manually delete the following files in your DESTDIR (which is 333b371a198Sriastradh usually $OBJDIR/destir.$ARCH), or from / if you have installed 334b371a198Sriastradh them: 335b371a198Sriastradh 336b371a198Sriastradh /libdata/firmware/radeon/bonaire_ce.bin 337b371a198Sriastradh /libdata/firmware/radeon/bonaire_mc.bin 338b371a198Sriastradh /libdata/firmware/radeon/bonaire_me.bin 339b371a198Sriastradh /libdata/firmware/radeon/bonaire_mec.bin 340b371a198Sriastradh /libdata/firmware/radeon/bonaire_pfp.bin 341b371a198Sriastradh /libdata/firmware/radeon/bonaire_rlc.bin 342b371a198Sriastradh /libdata/firmware/radeon/bonaire_sdma.bin 343b371a198Sriastradh /libdata/firmware/radeon/bonaire_smc.bin 344b371a198Sriastradh /libdata/firmware/radeon/bonaire_uvd.bin 345b371a198Sriastradh /libdata/firmware/radeon/hainan_ce.bin 346b371a198Sriastradh /libdata/firmware/radeon/hainan_mc.bin 347b371a198Sriastradh /libdata/firmware/radeon/hainan_me.bin 348b371a198Sriastradh /libdata/firmware/radeon/hainan_pfp.bin 349b371a198Sriastradh /libdata/firmware/radeon/hainan_rlc.bin 350b371a198Sriastradh /libdata/firmware/radeon/hainan_smc.bin 351b371a198Sriastradh /libdata/firmware/radeon/hawaii_ce.bin 352b371a198Sriastradh /libdata/firmware/radeon/hawaii_mc.bin 353b371a198Sriastradh /libdata/firmware/radeon/hawaii_me.bin 354b371a198Sriastradh /libdata/firmware/radeon/hawaii_mec.bin 355b371a198Sriastradh /libdata/firmware/radeon/hawaii_pfp.bin 356b371a198Sriastradh /libdata/firmware/radeon/hawaii_rlc.bin 357b371a198Sriastradh /libdata/firmware/radeon/hawaii_sdma.bin 358b371a198Sriastradh /libdata/firmware/radeon/hawaii_smc.bin 359b371a198Sriastradh /libdata/firmware/radeon/kabini_ce.bin 360b371a198Sriastradh /libdata/firmware/radeon/kabini_me.bin 361b371a198Sriastradh /libdata/firmware/radeon/kabini_mec.bin 362b371a198Sriastradh /libdata/firmware/radeon/kabini_pfp.bin 363b371a198Sriastradh /libdata/firmware/radeon/kabini_rlc.bin 364b371a198Sriastradh /libdata/firmware/radeon/kabini_sdma.bin 365b371a198Sriastradh /libdata/firmware/radeon/kaveri_ce.bin 366b371a198Sriastradh /libdata/firmware/radeon/kaveri_me.bin 367b371a198Sriastradh /libdata/firmware/radeon/kaveri_mec.bin 368b371a198Sriastradh /libdata/firmware/radeon/kaveri_mec2.bin 369b371a198Sriastradh /libdata/firmware/radeon/kaveri_pfp.bin 370b371a198Sriastradh /libdata/firmware/radeon/kaveri_rlc.bin 371b371a198Sriastradh /libdata/firmware/radeon/kaveri_sdma.bin 372b371a198Sriastradh /libdata/firmware/radeon/mullins_ce.bin 373b371a198Sriastradh /libdata/firmware/radeon/mullins_me.bin 374b371a198Sriastradh /libdata/firmware/radeon/mullins_mec.bin 375b371a198Sriastradh /libdata/firmware/radeon/mullins_pfp.bin 376b371a198Sriastradh /libdata/firmware/radeon/mullins_rlc.bin 377b371a198Sriastradh /libdata/firmware/radeon/mullins_sdma.bin 378b371a198Sriastradh /libdata/firmware/radeon/oland_ce.bin 379b371a198Sriastradh /libdata/firmware/radeon/oland_mc.bin 380b371a198Sriastradh /libdata/firmware/radeon/oland_me.bin 381b371a198Sriastradh /libdata/firmware/radeon/oland_pfp.bin 382b371a198Sriastradh /libdata/firmware/radeon/oland_rlc.bin 383b371a198Sriastradh /libdata/firmware/radeon/oland_smc.bin 384b371a198Sriastradh /libdata/firmware/radeon/pitcairn_ce.bin 385b371a198Sriastradh /libdata/firmware/radeon/pitcairn_mc.bin 386b371a198Sriastradh /libdata/firmware/radeon/pitcairn_me.bin 387b371a198Sriastradh /libdata/firmware/radeon/pitcairn_pfp.bin 388b371a198Sriastradh /libdata/firmware/radeon/pitcairn_rlc.bin 389b371a198Sriastradh /libdata/firmware/radeon/pitcairn_smc.bin 390b371a198Sriastradh /libdata/firmware/radeon/tahiti_ce.bin 391b371a198Sriastradh /libdata/firmware/radeon/tahiti_mc.bin 392b371a198Sriastradh /libdata/firmware/radeon/tahiti_me.bin 393b371a198Sriastradh /libdata/firmware/radeon/tahiti_pfp.bin 394b371a198Sriastradh /libdata/firmware/radeon/tahiti_rlc.bin 395b371a198Sriastradh /libdata/firmware/radeon/tahiti_smc.bin 396b371a198Sriastradh /libdata/firmware/radeon/verde_ce.bin 397b371a198Sriastradh /libdata/firmware/radeon/verde_mc.bin 398b371a198Sriastradh /libdata/firmware/radeon/verde_me.bin 399b371a198Sriastradh /libdata/firmware/radeon/verde_pfp.bin 400b371a198Sriastradh /libdata/firmware/radeon/verde_rlc.bin 401b371a198Sriastradh /libdata/firmware/radeon/verde_smc.bin 402b371a198Sriastradh 403b371a198Sriastradh We will re-import these radeon firmware images another way 404b371a198Sriastradh later. 405b371a198Sriastradh 406c628b06cSmartin20190727: 407c628b06cSmartin The uefi bootloader has gained tftp support and needs a clean 408c628b06cSmartin build. If you do update builds, manually clean its object 409c628b06cSmartin directory by something like: 410c628b06cSmartin cd sys/arch/i386/stand/efiboot && make clean 411c628b06cSmartin 4129aa5d31cSmartin20190723: 4139b222ad1Sgutteridge The jemalloc allocator in libc is now built without extended 4149aa5d31cSmartin debugging (for performance reasons). In update builds make sure 415f273a7a1Sandvar to rebuild it completely, by removing all affected object files, 4169aa5d31cSmartin including compat builds, something like: 4179aa5d31cSmartin cd /usr/obj && find . -type d -name jemalloc|xargs rm -rf 4189aa5d31cSmartin 41937a83360Smrg20190207: 42037a83360Smrg GCC 7 switched for many ports. Update builds are likely to fail. 42137a83360Smrg 422f1de59e0SpgoyetteHints for a more successful build: 423f1de59e0Spgoyette^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 424f1de59e0Spgoyette Use build.sh, but do not use its "expert mode": 425f1de59e0Spgoyette This will automatically build the tools in the 426f1de59e0Spgoyette correct order, and it will keep the tools and the 427f1de59e0Spgoyette new build products from interfering with the running 428f1de59e0Spgoyette system. This will allow you to ignore most of the 429f1de59e0Spgoyette other advice in this file. 430f1de59e0Spgoyette Build a new kernel first: 431f1de59e0Spgoyette This makes sure that any new system calls or features 432f1de59e0Spgoyette expected by the new userland will be present. This 433f1de59e0Spgoyette helps to avoid critical errors when upgrading. 434f1de59e0Spgoyette Use object directories: 435f1de59e0Spgoyette This helps to keep stale object 436f1de59e0Spgoyette files from polluting the build if a Makefile "forgets" 437f1de59e0Spgoyette about one. It also makes it easier to clean up after 438f1de59e0Spgoyette a build. It's also necessary if you want to use the 439f1de59e0Spgoyette same source tree for multiple machines. 440f1de59e0Spgoyette To use object directories with build.sh: 441f1de59e0Spgoyette a) invoke build.sh with the "-M" or "-O" options. 442f1de59e0Spgoyette To use object directories without using build.sh: 443f1de59e0Spgoyette a) cd /usr/src ; make cleandir 444f1de59e0Spgoyette b) Add "OBJMACHINE=yes" to /etc/mk.conf 445f1de59e0Spgoyette c) Add "MKOBJDIRS=yes" to /etc/mk.conf 446f1de59e0Spgoyette d) cd /usr/src ; make build 447f1de59e0Spgoyette Note that running "make obj" in a directory will create 448f1de59e0Spgoyette in obj.$MACHINE directory. 449f1de59e0Spgoyette Build to a DESTDIR: 450f1de59e0Spgoyette This helps to keep old installed files (especially libraries) 451f1de59e0Spgoyette from interfering with the new build. 452f1de59e0Spgoyette To build to a DESTDIR with build.sh, use the "-D" option. 453f1de59e0Spgoyette To build to a DESTDIR without using build.sh, set the DESTDIR 454f1de59e0Spgoyette environment variable before running make build. It should be 455f1de59e0Spgoyette set to the pathname of an initially empty directory. 456f1de59e0Spgoyette Problems: if you do not use build.sh, you might need to 457f1de59e0Spgoyette update critical utilities without using DESTDIR since 458f1de59e0Spgoyette nothing is executed from what is installed in DESTDIR. 459f1de59e0Spgoyette (See critical utils, below.) 460f1de59e0Spgoyette Build often: 461f1de59e0Spgoyette This keeps critical utilities current enough to not choke 462f1de59e0Spgoyette on any other part of the source tree that depends on up to 463f1de59e0Spgoyette date functionality. If you use build.sh, you should not have 464f1de59e0Spgoyette this problem. 465f1de59e0Spgoyette 466f1de59e0SpgoyetteWhat to do if things don't work: 467f1de59e0Spgoyette^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 468f1de59e0SpgoyetteWhen things don't work there are usually a few things that commonly 469f1de59e0Spgoyetteshould be done. 470f1de59e0Spgoyette 1) make includes 471f1de59e0Spgoyette This should be done automatically by make build. 472f1de59e0Spgoyette 2) cd share/mk && make install 473f1de59e0Spgoyette Again, automatically done by make build. 474f1de59e0Spgoyette 475f1de59e0SpgoyetteFailsafe rebuild of a small part of the tree: 476f1de59e0Spgoyette^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 477f1de59e0SpgoyetteTo make sure you rebuild something correctly you want to do 478f1de59e0Spgoyettesomething like the following: 479f1de59e0Spgoyette 1) Make sure the includes and .mk files are up to date. 480f1de59e0Spgoyette 2) Make sure any program used to build the particular 481f1de59e0Spgoyette utility is up to date. (yacc, lex, etc...) 482f1de59e0Spgoyette 3) cd ...path/to/util... 483f1de59e0Spgoyette make cleandir 484f1de59e0Spgoyette rm ...all obj directories... 485f1de59e0Spgoyette make cleandir # yes, again 486f1de59e0Spgoyette make obj 487f1de59e0Spgoyette make depend && make 488f1de59e0Spgoyette 489f1de59e0SpgoyetteFailsafe rebuild of the entire tree: 490f1de59e0Spgoyette^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 491f1de59e0SpgoyetteIf you really want to make sure the source tree is clean and 492f1de59e0Spgoyetteready for a build try the following. Note that sourcing /etc/mk.conf 493f1de59e0Spgoyette(a make(1) Makefile) in this manner is not right, and will not work 494f1de59e0Spgoyettefor anyone who uses any make(1) features in /etc/mk.conf. 495f1de59e0Spgoyette 496f1de59e0Spgoyette---cut here--- 497f1de59e0Spgoyette#!/bin/sh 498f1de59e0Spgoyette. /etc/mk.conf 499f1de59e0Spgoyette 500f1de59e0Spgoyetteif [ -z $NETBSDSRCDIR ] ; then 501f1de59e0Spgoyette NETBSDSRCDIR=/usr/src 502f1de59e0Spgoyettefi 503f1de59e0Spgoyetteif [ \! -d $NETBSDSRCDIR ] ; then 504f1de59e0Spgoyette echo Unable to find sources 505f1de59e0Spgoyette exit 1 506f1de59e0Spgoyettefi 507f1de59e0Spgoyettefind $NETBSDSRCDIR -name \*.o -o -name obj.\* -o -name obj -exec rm \{\} \; 508f1de59e0Spgoyette 509f1de59e0Spgoyetteif [ -z $BSDOBJDIR ] ; then 510f1de59e0Spgoyette BSDOBJDIR=/usr/obj 511f1de59e0Spgoyettefi 512f1de59e0Spgoyetteif [ -d $BSDOBJDIR ] ; then 513f1de59e0Spgoyette rm -rf $BSDOBJDIR 514f1de59e0Spgoyettefi 515f1de59e0Spgoyette 516f1de59e0Spgoyettecd $NETBSDSRCDIR && make cleandir 517f1de59e0Spgoyette 518f1de59e0Spgoyette---cut here--- 519f1de59e0Spgoyette 520f1de59e0SpgoyetteCritical utilities: 521f1de59e0Spgoyette^^^^^^^^^^^^^^^^^^^ 522f1de59e0Spgoyette usr.bin/make 523f1de59e0Spgoyette usr.bin/yacc 524f1de59e0Spgoyette usr.bin/lex 525f1de59e0Spgoyette usr.bin/xlint 526f1de59e0Spgoyette usr.bin/config 527f1de59e0Spgoyette 528f1de59e0SpgoyetteOther problems and possible solutions: 529f1de59e0Spgoyette^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 530f1de59e0SpgoyetteSymptom:Complaints involving a Makefile. 531f1de59e0SpgoyetteFix: Rebuild usr.bin/make: 532f1de59e0Spgoyette cd usr.bin/make && make && make install 533f1de59e0Spgoyette Or, a failsafe method if that doesn't work: 5340800ba3eSrillig cd usr.bin/make && cc -DMAKE_NATIVE *.c -I. -o make \ 5350800ba3eSrillig && install make /usr/bin 536f1de59e0Spgoyette 537f1de59e0SpgoyetteFix: Make sure .mk files are up to date. 538f1de59e0Spgoyette cd share/mk && make install 539f1de59e0Spgoyette 540f1de59e0SpgoyetteSymptom:Kernel `config' fails to configure any kernel, including GENERIC. 541f1de59e0SpgoyetteFix: Rebuild usr.bin/config 542f1de59e0Spgoyette 543f1de59e0SpgoyetteSymptom:Obsolete intermediate files are used during compilation 544f1de59e0SpgoyetteFix: Try the following sequence of commands in the directory in question. 545f1de59e0Spgoyette make cleandir; rm `make print-objdir`; make cleandir; make obj 546f1de59e0Spgoyette (If you built the tree without "make obj" in the past, obsolete files 547f1de59e0Spgoyette may remain. The command tries to clean everything up) 548f1de59e0Spgoyette 549f1de59e0SpgoyetteSymptom:.../sysinst/run.c:xx: warning: initialization from incompatible 550f1de59e0Spgoyette pointer type 551f1de59e0SpgoyetteFix: Rebuild and install usr.bin/menuc 552f1de59e0Spgoyette 553f1de59e0SpgoyetteSymptom:mklocale not found during build in share/locale/ctype 554f1de59e0SpgoyetteFix: Build and install usr.bin/mklocale 555f1de59e0Spgoyette 556f1de59e0SpgoyetteSymptom:undefined reference to `__assert13' or `__unsetenv13' 557f1de59e0SpgoyetteFix: Rebuild and install lib/libc 558f1de59e0Spgoyette 559f1de59e0SpgoyetteSymptom:usr.bin/config fails to build. 560f1de59e0SpgoyetteFix: Try building with -DMAKE_BOOTSTRAP added to CFLAGS in Makefile. 561f1de59e0Spgoyette 562f1de59e0SpgoyetteSymptom:undefined reference to `getprogname' or `setprogname' 563f1de59e0SpgoyetteFix: Rebuild and install lib/libc 564f1de59e0Spgoyette 565f1de59e0SpgoyetteSymptom:Update build fails in src/tools/gcc complaining that a variable 566f1de59e0Spgoyette (e.g. CPPFLAGS) has changed since the previous run. 567f1de59e0SpgoyetteFix: Run "nbmake-${ARCH} clean" in src/tools/gcc or do a clean build. 568f1de59e0Spgoyette 569f1de59e0SpgoyetteSymptom:cvs [update aborted]: cannot open directory /cvsroot/src/...: 570f1de59e0Spgoyette No such file or directory. 571f1de59e0SpgoyetteCause: If a directory is created by mistake, then it is sometimes 572f1de59e0Spgoyette deleted from the CVS repository using administrative commands 573f1de59e0Spgoyette that bypass the normal cvs access controls. If your cvs working tree 574f1de59e0Spgoyette contains references to a directory that has been deleted on the 575f1de59e0Spgoyette server in this way, then "cvs update" reports this error. 576f1de59e0SpgoyetteFix: Recursively delete the affected directory from your working tree 577f1de59e0Spgoyette and try the update again. 578