diff --git a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml index 9c2c604b53..c8ef3f0698 100644 --- a/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml +++ b/en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml @@ -2441,18 +2441,16 @@ Script done, … - Questions + Common Questions - - - - Do I need to re-make the world for every - change? - + + + Do I need to re-make the world for every + change? - - There is no easy answer, as it depends on the nature - of the change. For example, if running + + It depends upon the nature + of the change. For example, if svn only shows the following files as being updated: @@ -2465,108 +2463,77 @@ Script done, … it probably is not worth rebuilding the entire world. Instead, go into the appropriate sub-directories and run make all install. But if - something major changed, such as - src/lib/libc/stdlib, either - re-make world, or at least those parts of it that are - statically linked. + something major changes, such as + src/lib/libc/stdlib, consider + rebuilding world. - At the end of the day, it is your call. Some users - re-make the world every fortnight and let changes + Some users + rebuild world every fortnight and let changes accumulate over that fortnight. Others only re-make those things that have changed and are careful to spot - all the dependencies. - - It all depends on how often a user wants to upgrade + all the dependencies. It all depends on how often a user wants to upgrade and whether they are tracking &os.stable; or &os.current;. - - + + - - - My compile failed with lots of + + What would cause a compile to fail with lots of signal 11 signal 11 - (or other signal number) errors. What happened? - + (or other signal number) errors? - - This normally indicates hardware problems. - (Re)making world is an effective way to stress test - hardware, and will frequently throw up memory - problems which normally manifest themselves as the - compiler mysteriously aborts. - - A sure indicator of this occurs when + + This normally indicates a hardware problem. + Building world is an effective way to stress test + hardware, especially memory. A sure indicator of a hardware issue is when make is restarted and it dies at a different point in the process. - To resolve this error, start swapping around the - components in the machine to determine which one is + To resolve this error, swap out the + components in the machine, starting with RAM, to determine which component is failing. - - + + - - - Can /usr/obj - be removed when finished? - + + Can /usr/obj + be removed when finished? - - The short answer is yes. + - /usr/obj + This directory contains all the object files that were produced during the compilation phase. Normally, one of the first steps in the make buildworld process is to remove this directory and start afresh. Keeping /usr/obj around when finished makes little sense, and its removal frees - up a approximately 2 GB of disk space. + up a approximately 2GB of disk space. + + - Advances users can instruct - make buildworld to skip this step. - This speeds up subsequent builds, since most of the - sources will not need to be recompiled. The flip side - is that subtle dependency problems can creep in, causing - the build to fail in odd ways. This frequently - generates noise on the &os; mailing lists, when one - person complains that their build has failed, not - realizing that it is because they have tried to cut - corners. - - + + Can interrupted builds be resumed? - - - Can interrupted builds be resumed? - - - + This depends on how far into the process the - problem occurs. - - In general, make buildworld - builds new copies of essential tools, such as - &man.gcc.1; and &man.make.1;, and the system libraries. + problem occurs. In general, make buildworld + builds new copies of essential tools and the system libraries. These tools and libraries are then installed, used to - rebuild themselves, and are installed again. The entire - system, including regular user programs such as - &man.ls.1; or &man.grep.1;, is then rebuilt with the new - system files. + rebuild themselves, and are installed again. The rest of the + system is then rebuilt with the new + system tools. - During the last stage, it is fairly safe to: + During the last stage, it is fairly safe to run + these commands as they will not undo the work of the previous + make buildworld: - … fix the problem … -&prompt.root; cd /usr/src + &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all - This will not undo the work of the previous - make buildworld. - - If you see the message: + If this message appears: -------------------------------------------------------------- Building everything.. @@ -2575,72 +2542,36 @@ Building everything.. in the make buildworld output, it is probably fairly safe to do so. - If that message is not displayed, or you are not - sure, it is always better to be safe than sorry, and + If that message is not displayed, + it is always better to be safe than sorry and to restart the build from scratch. - - + + - - - How can I speed up making the world? - + + Is it possible to speed up making the world? - - - - Run it in single user mode. - + + Several actions can speed up the build world + process. For example, the entire process can be run from + single-user mode. However, this will prevent users + from having access + to the system until the process is complete. - - Put /usr/src and - /usr/obj - on separate file systems held on separate disks. If - possible, put these disks on separate disk - controllers. - + Careful file system design or the use of ZFS + datasets can make a difference. Consider putting /usr/src and + /usr/obj + on separate file systems. If possible, place the file systems on separate disks on separate disk + controllers. When mounting + /usr/src, use + which + prevents the file system from recording the + file access time. If /usr/src is not on its + own file system, consider remounting /usr with . - - Alternately, put these file systems across - multiple disks using &man.ccd.4;. - - - - Turn off profiling by setting - NO_PROFILE=true in - /etc/make.conf. - - - - Pass - - to &man.make.1; to run multiple processes in - parallel. This usually helps on both single and - multi processor machines. - - - - The file system holding - /usr/src can - be mounted or remounted with - . - This prevents the file system from recording the - file access time which is probably not - needed. - - &prompt.root; mount -u -o noatime /usr/src - - - This example assumes - /usr/src is on its own file - system. If it is part of - /usr, then use that file - system mount point instead. - - - - - The file system holding + The file system holding /usr/obj can be mounted or remounted with so that disk writes happen asynchronously. The write completes @@ -2663,25 +2594,22 @@ Building everything.. backups before enabling this option. - &prompt.root; mount -u -o async /usr/obj + Turn off profiling by setting + NO_PROFILE=true in + /etc/make.conf. - - If /usr/obj is - not on its own file system, replace it in the - example with the name of the appropriate mount - point. - + Pass + + to &man.make.1; to run multiple processes in + parallel. This usually helps on both single- and + multi-processor machines. - - - + - - - What do I do if something goes wrong? - + + What do I do if something goes wrong? - + Make absolutely sure that the environment has no extraneous cruft from earlier builds: @@ -2701,9 +2629,9 @@ Building everything.. output of uname -a to &a.questions;. Be prepared to answer other questions about the setup! - - - + + +