LFS-6.6, Stage2, glibc, nscd.c:442

Ken Moffat zarniwhoop73 at googlemail.com
Mon May 31 16:34:52 PDT 2010

On 31 May 2010 17:35, Paul Rogers <paulgrogers at fastmail.fm> wrote:

>>  What you are overlooking is that "doing it my way" comes with "when
>>  it breaks, I get to keep all the pieces".
> What a curious thing to write in a SUPPORT forum of a LINUX distribution
> with the motto, "YOUR DISTRO, YOUR RULES."  I can't interpret that in
> any way that seems to be helpful.  This is Linux, it has always been
> thus.  That's hardly original, I've seen essentially the same admonition
> in many of the FOSS packages that make a useful system.  In point of
> fact, I have completely replaced the init.d/rc code with my own from the
> principle, "I know what I started, if it's to be stopped I'll stop it
> when I leave."  Each numbered runlevel assumes it was the first one
> started, and will be the last one running before shutdown.  "From dust I
> came, to dust I will return."  I don't need lock file semaphores to
> communicate between run levels what has been started.  It works very
> well, all the pieces are mine, and none of them are broken thank you
> very much, even if LSB incompliant.  But otherwise the core of my build
> scripts come straight from the book.  I think it's highly desireable to
> have a core Linux/GNU base that's a clean, known quantity.  The key
> organizing paradigm of "my distro" is KISS.

 You have, I think, mentioned that you are using package management.
You are also using a much older host system than most people have
available.  When you make your own path, nobody has any experience
of the differences..  It might be an interesting intellectual exercise to
tear it apart and eventually discover where the problem lies, but it's
not a good use of our time.

 And no, the phrase is not supposed to be original.  It's a statement of
the reality, as I see it.
>> I too use my own scripts, and from time to time I've been a long way
>> from current LFS (variously working on BLFS using an old version, or
>> using clfs when x86_64 was not in LFS, or doing other things), and
>> sometimes I've been tearing my hair out.
> I'm not an adventurer.  In most respects I'm a computer user, though
> perhaps an "early adopter".  Computers have always been TOOLS to me.  I
> build them, since my IMSAI in 1976, because I must in order to use them.
>> In general, building from the previous release (or newer) is usually
>> tested by the time we have a release, because that's what editors and
>> other people using the development book are typically using.  Using
>> the release before the previous release might work, particularly if
>> you have updated the kernel version since you built it.  The 6.3
>> release (on i686) probably works because a lot of people still use the
>> Live CD.  For anything else, you're on your own.
> That's fine.  But your book's HSR, that little script that's included,
> tells me, except for the kernel version, my 6.1 system is "good to go."
>>  But as to what versions are *required*, we have no data!
> What's the HSR if not exactly that?  Granted, it seems there wasn't
> enough exploration done to verify what gcc/kernel was required, as
> linuxfan recently posted.

 It's the versions that seemed to work when that page was last revised.
If you eventually track down a better version, you can raise a ticket, and
the book will be updated - until the next time that version is too old.

>>  I'm also worried by your phrase "Except that also brings along X &
>>  xfce, et al." - those are outside the host system, do you think that
>>  building from an xterm somehow leads to a different result than
> Of course not!  Nor does using the extra stuff in my script template.
> That's why I have little patience for a SUPPORT TEAM overusing FBBG.
> It's MY responsibility to see I'm not subverting the book's process, but
> given that I don't expect the response to a problem to be withdrawal and
> shouts of, "Unclean!  Unclean!"

 The "support team" is whoever happens to chime in on a thread.  Most
people here are well-intentioned, and we use our own experience both
in building and in the problems we've seen mentioned.  I'm happy to
ignore your future postings in this thread if I'm not helping.
>>  building from a tty ?  If that is indeed the case, you are probably
>> better building under xorg, because that is the more common case.
> Yes, my 6.1 uses XOrg-6.8.2, and I expect to install 7.5 with 6.6, if I
> can only get THAT built.
>> I am dubious about your old version of gcc (because it has
>> difficulties correctly compiling a current kernel on x86 - see
> Then don't list gcc-3.0.1 and linux-2.6.18 in the HSR's!
>> be your kernel version.  If you can update to latest 2.6.27 (which
>> still has a long-term-stable version), you might be in with a chance -
>> if that doesn't help, your old version of gcc is  almost certainly the
>> problem.
> Except that Pete Jordan's -lssp workaround seemed to work for him.
>> Let's look at this another way - most people who try the development
> What "development"?  I go to the website, Read on-line, Stable LFS, and
> I get the 6.6 book!  This book is supposed to be for general
> consumption.

 Again, I'm talking about how the book is *developed*.  You might think
there is a long period when a version of the book is marked as a release
candidate, and a large QA team then looks at the wording and tests it
on as many old hosts as they can lay their hands on.  Doesn't happen
like that.  At some point, an rc is made.  The people who have followed
the development book might review it and test it on old hosts, or they
might not.  We usually get a few new people trying it..

 The 'stable' book *is* for general consumption.  Doesn't mean it's
perfect, doesn't mean it will work for people using old systems.

>> book are either using a very-recent LFS, or a recent distro (recent
>> kernel, recent toolchain).  After it becomes a release, we might get a
>> few users with slightly older LFS hosts.  If you have unusual
>> problems, and you are following the correct procedures, the most
>> likely cause is that your host system is inadequate.
> 6.6 is a stable release.  I've got a 6.1 system, which builds gcc-3.4.3.
> The book says I need 3.0.1 or better.  Did you mean 4.0.1?  That's not
> what it says.  And, "There are no current errata items for LFS 6.6."

 If you build LFS, you pick up enough skills to do it again.  If you were using
a regular distro, they would update it during the distro's life, and move it to
a newer release.  Because you build it yourself, you have to make the
decision about when to upgrade.  I suggest that a system lifetime of nearly
5 years is "rather longer" than most people would attempt to keep a desktop
in use.
>> By the way, you _do_ need to remove toolchain source directories after
>> each stage.  Something you wrote made me question whether you had been
>> doing that throughout your build.
> Of course.  And I even know that WASN'T always the case in earlier
> builds.

 It was always intended, but probably not always mentioned.

> What I wrote was that I have saved the directories from my
> Saturday excursion "in another partition", but in any case after that
> I was restoring previously built code, not redoing the rest of the
> Stage1 build.
>> I wish you good luck, but if you can build from a Live CD, that
>> appears to be a more productive use of your time than identifying
>> exactly *what* needs to be upgraded beyond the minimum requirements
>> listed in the book.  Of course, definitive information that a
>> particular version of a package is now needed is good for the book,
>> but ascertaining the exact version will usually be painful (plus, I
>> doubt we would revise a release for that information).
> Now that you have information that gcc-4.2 is required to compile the
> stack protector kernel code, I expect at least an erratum to the HSR is
> called for.  And that causes me to question the 6.3 book, which builds
> an earlier version of gcc, as I recall.
>> I'm also slightly worried by the implication in your post that "any
>> random version of what is in BLFS will do".  Maybe you didn't mean
>> that, but
> Did I write that?  I don't think I wrote that.  I don't remember even
> seeing that.

OK, I've put words into your mouth there.  I withdraw that comment.


After tragedy, and farce, "OMG poneys!"

More information about the lfs-support mailing list