[lfs-support] still doesnt work right (after binutils pass 2)
zarniwhoop at ntlworld.com
Wed Nov 14 11:52:21 PST 2012
On Wed, Nov 14, 2012 at 11:13:03AM -0800, Paige Thompson wrote:
> I don't understand.
> commit ee9247c38a8def24a59eb5cfb7196a98bef8cfdc
> Author: Carlos O'Donell <carlos_odonell at mentor.com>
> Date: Sat Jun 30 08:27:06 2012 -0700
> Update NEWS and README.
> Final update for 2.16 release.
> 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 ;-)
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-support