<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 8:03 AM, Andrew Bradford <span dir="ltr"><<a href="mailto:andrew@bradfordembedded.com" target="_blank">andrew@bradfordembedded.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 10/21/13 17:22, nu shto wrote:<br>
> Just one stylistic comment: I think it'd be worthwhile to point out how the<br>
> gcc-final build differs from the gcc-static build. I know it is pointed out<br>
> in the introduction, but it might be helpful to reiterate what is going on.<br>
> I found myself pausing to make sure that there wasn't just a problem in the<br>
> book since I had just built gcc and now I was suddenly building it again<br>
> with what appeared to be an identical procedure (it's hard to mentally diff<br>
> long strings of configure flags).<br>
<br>
</div>Yes, that's a good idea. Basically, you build GCC the first time so<br>
that you can cross build the libc. Then you build GCC again, using that<br>
cross built libc, so that you can build userspace software (ie:<br>
everything except libc, kernel, and bootloader).<br>
<br>
If I add something like that, does that make it more clear?<br></blockquote><div> </div><div>Yeah, I think something along those lines should be sufficient. I think any cue to the reader (other than the title) that this set of instructions, while similar, is in fact different than the previous step, would be fine.</div>
<div><br></div><div>Looking back, I think maybe the other reason why I found it confusing is that the build directory names for both GCCs are the same (later I realized that the assumption is that you have to delete the old build folder once you're done with it). </div>
<div><br></div><div>Compiler bootstrapping is one of those magical things in computers that I understand rationally but still makes my brain hurt slightly. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> Also, a few trivial writing problems:<br>
><br>
> $ git diff<br>
> diff --git a/BOOK/bootable/common/kernel.xml<br>
> b/BOOK/bootable/common/kernel.xml<br>
> index d227fa2..e2acf5b 100644<br>
> --- a/BOOK/bootable/common/kernel.xml<br>
> +++ b/BOOK/bootable/common/kernel.xml<br>
> @@ -45,7 +45,7 @@<br>
> components are console/video, disk, and network. With out these<br>
> built<br>
> in, the system will not function properly. It is recommended to<br>
> configure the kernel without modules in order to conserve disk<br>
> space<br>
> - and to simplify.</para></note><br>
> + and to simplify (the boot process, or ...<br>
> what?).</para></note><br>
<br>
</div>I didn't have a good next word so I put a period :)<br>
Not having modules makes things less complex. Got any recommendations?<br>
<br>
The main thing is that building and installing modules may require you<br>
to then have an initramfs, modprobe configuration, deal with u/mdev,<br>
etc. I want to avoid explaining all that as it's not needed on an<br>
embedded system, usually. Just build a kernel and boot it.<br></blockquote><div><br></div><div>This is why my first thought went to "... simplify the boot process" -- because dealing with initramfs and modules seriously reduces the chances of a novice getting their kernel to even boot. And if you can't get it to boot, I feel like you're much more likely to just give up on the whole thing. Perhaps something along the lines of "... and to eliminate several module-related steps that, if done incorrectly, can prevent the kernel from booting." </div>
<div><br></div><div>or perhaps more simply: </div><div><br></div><div>".... and to reduce the amount of configuration necessary to boot the kernel."</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> diff --git a/BOOK/materials/common/creatingbuilddir.xml<br>
> b/BOOK/materials/common/creatingbuilddir.xml<br>
> index 0f809de..54f1c6c 100644<br>
> --- a/BOOK/materials/common/creatingbuilddir.xml<br>
> +++ b/BOOK/materials/common/creatingbuilddir.xml<br>
> @@ -19,7 +19,7 @@<br>
><br>
> <screen><userinput>export CLFS=/mnt/clfs</userinput></screen><br>
><br>
> - <para>Ensure that this new directory has permissions that are too<br>
> restrictive<br>
> + <para>Ensure that this new directory has permissions that are not too<br>
> restrictive<br>
> such that you can write to it as a non-root user.</para><br>
><br>
> <screen><userinput>chmod 777 ${CLFS}</userinput></screen><br>
<br>
</div>Thanks! Applied to my local git, will go with next pull req (probably<br>
later today).<br>
<span class=""><font color="#888888"><br>
-Andrew<br>
<br>
</font></span></blockquote></div><br></div></div>