On Wed, Nov 14, 2012 at 11:13:03AM -0800, Paige Thompson wrote: > I don't understand. > > commit ee9247c38a8def24a59eb5cfb7196a98bef8cfdc > > Author: Carlos O'Donell <carlos_odon...@mentor.com> > > Date: Sat Jun 30 08:27:06 2012 -0700 > > > > Update NEWS and README. > > > > Final update for 2.16 release. > > http://www.kernel.org/doc/man-pages/online/pages/man2/arch_prctl.2.html > > > > how is it that it thinks I have glib 2.7, that commit is what my glibc tree > is at. so .
Please read, and think about, the reply I sent a few minutes ago. I didn't see the reference to glib-2.7 or glibc-2.7, but I am confident that you will find things simpler if you *start* by following the book. If you want to build everything from scratch, picking bits and pieces from LFS for the foundations, you will be on your own when things break. If you start with LFS, done by-the-book, you should know enough to then either use the LFS build to do things your own way, and be able to compare them when things break, or to keep it around and build things your way from your current host system, again comparing the two when you get problems. For building everything in a system from source, or even for only building what is in LFS itself, I find it helpful to not change too many package versions on each build - this helps me keep on top of what has changed, and what causes the need for a fix. Obviously, when something is in LFS-svn it works for at least one editor (barring typos) so you should be able to take that as a fairly reliable base - but it *will* still break random packages in what we call BLFS from time to time. If you are maintaining your own system, it is generally easier to change a little, sort that out, and then repeat again. In theory, the linux kernel builds (for linus :) with each git version that he commits - that doesn't mean it builds and works for everyone. Many other packages are more likely to be broken for some users at a random revision. Alternatively, maybe you are using git to pull specific *releases* - in that case, isn't it easier to use (and keep) the tarballs ? That way, you can use e.g. md5sums to check that what you are using is what others are using, and you can search the distros to see what patches they apply : for LFS we occasionally find fixes in the distros (when we try a new package version and hit a problem somewhere), but mostly the useful stuff is for the later (BLFS) packages. And keeping everything reasonably up-to-date *does* take an awful lot of time! If you do things your own way, we *might* sometimes be able to help, but you will get better responses if you can identify what you are doing which is different from the book. So far I have picked up that you are building in VirtualBox, using a directory other than /mnt/lfs, and not building binutils-pass-1 in the way that we do. If you start as I have suggested, and still get problems trying to build binutils-pass-1 the way that we do, please post again in a new thread. I'm 98% confident that if you follow what I wrote in my last reply, and stop immediately (and ask for advice - google might help, but only if your current experience allows you to filter out the noise, so you could ask if you have any doubt about suggested fixes), then you will succeed. The 2% is because I have no idea how to set up VirtualBox ;-) FBBG. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
