On Tue, 15 Dec 2015 15:07:21 -0800 Paul Rogers <[email protected]> wrote:
> > >How common is this? > > Building a 64 bit system is common. Encountering a binary which > > requires specific libraries can be common if you do it all the time. I > > can remember java, acrobat, wine and some other binaries I can't > > remember right now. > > So you're suggesting I go pure 64? X drivers all OK with 64? I've built complete pure 64bit systems up to a full Plasma5 desktop without issue. It will work fine. > > > > How does one know how to plan for the "BLFS" stage? > > We build a few systems and figure out what is exactly needed. If you > > stick with CLFS multilib, use the cblfs.clfs.org wiki for a guide and > > use BLFS with updated packages. You'll need the multiarch wrapper and > > most packages will require --libdir=/usr/lib64 for 64bit along with > > PKG_CONFIG_PATH and USE_ARCH variables. > > > > Keep it simple, if you don't need multilib, don't do it. It's a > > headache. > > So if I go pure 64, then all the headers and libraries all work out > automagically, and I can pretty much ignore the differences? > If you go pure 64bit, you'll disable multilib and thus only need to deal with a 64bit toolchain. > > > After an x86-64 system is created, and would be the host for future > > > development, then what? Presumably the next system doesn't need to > > > be cross-compiled. Can one use the regular LFS book? I just want > > > to know what it "means" to make the shift. > > > > You can build CLFS through cross-tools and temp-system, and then > > follow LFS book after chroot or by the boot method without issues. > > I think maybe we're talking about different things. If I make a pure 64 > CLFS system, then in a couple years found some reason to need an update, > do I have to go back to make a new CLFS, or as I asked above, does > everything work out and I can follow the LFS book again? If you end up having to upgrade the toolchain, may as well build a whole new LFS build. > > > With CLFS, we include graphite loop optimization support, where LFS > > doesn't. If you require that, then you need to build CLFS in chroot or > > by boot method through GCC, then you can use LFS. > > Graphite loop? Wozzat? Never heard of that before, being pure LFS-32. > Why would I require that? > If you don't know why, then you most likely don't need it. By the way, anyone who wants to add that for GCC 5.2.0 and later, it includes one package. ISL 0.15. If using GCC 5.3.0 the header issues with a vanilla 5.2.0 are ironed out, or you can checkout gcc 5.2.0 branch and apply the current changes with the fix regarding graphite headers. Additional reading if desired: https://gcc.gnu.org/wiki/Graphite https://gcc.gnu.org/wiki/ISLCodeGenerator http://isl.gforge.inria.fr/ > Sounds like MAYBE that last clause answers my queston in the last > paragraph? > > > If your current machine is multilib, then you can't blindly follow LFS > > Just LFS-7.2 with updated Firefox & OpenJDK. > > > instructions. You have to keep the multilib instructions in your > > build. LFS isn't multilib. Even though you don't need to cross- > > compile, you still need the multilib instructions. > > But going from where I am up to pure 64, I wouldn't? SO, since you are going with pure64 bit, then you just got rid of a bunch of headaches and you can build your system and use BLFS without issue. LFS and BLFS is really what it sounds like you want to use. Sincerely, William Harrington -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
