On Jan 13, 2012, at 1:50 AM, Nathan Coulson wrote: > On Thu, Jan 12, 2012 at 1:32 PM, Bruce Dubbs <bruce.du...@gmail.com> wrote: >> >> >> If we don't add things like an initramfs to the book, we will probably >> need to limit what our users can do.
Initramfs is widely used everywhere else, so at the least, even if it's not widely used among LFSers, the educational value is quite high. > Personally, I loved the fact that LFS kept up with the latest & > greatest technologies, while still following existing standards. > (Although sometimes we had others who tested out the bleeding edge > waters). Our move to grub, linux 2.6, udev, grub2, then 64bit was > exciting to follow, and I loved the direction we went. > (I wonder if I am the only one who misses such grand changes... > things seem more stabler these days). Nope! I miss it too. LFS used to have a lot more activity, with the separate hackers list and work being done on branches with new concepts. Of course, we also had a lot more flame wars then too - wish I could say I was just an innocent bystander in those. :( > One last thing I would like to open up to the floor, the use of > "-B/tools/lib/" in chapter 5. > > Would it be possible to look into using something like sysroot for > /tools as opposed to defining CC/AR/RANLIB? It always felt more > complicated then what we need, and I can not make it work for my own > personal LFS (multilib, for 64bit, and 32bit) You could definitely kill -B. Ryan Oliver helped me develop a cross->native build without it and using sysroot a couple of years back. I've used it successfully recently to bootstrap the dev environment I needed for LightCube OS. You could also adjust gcc slightly so it only looks in /lib:/usr/lib. That way we don't need a /lib64 symlink on x86_64. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
