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

Paul Rogers paulgrogers at fastmail.fm
Mon May 31 09:35:50 PDT 2010

> Possibly.  The problem may be not using gcc-4.x.

So it seems, though grepping the kernel sources for 2.6.18 didn't
turn up any usage of PROTECTOR which would be in .config, hence
a matching string in it's configure/makefiles.  So I expect.

> My advice would be to use jhalfs for some arbitrary version of the
> book that you choose and just let it run.  We know that LFS-6.3 works
> because it has been used a lot from the last LiveCD.  That would be a
> good candidate for an intermediate release.

No, if I decide to "double my fun", I'll make 6.3 a "normal" upgrade
from my current 6.1 version.  I am determined to have a consistent path.

>  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.

> 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.

>  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!"

>  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

> 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."

> 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.  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.
Paul Rogers
paulgrogers at fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)


http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again

More information about the lfs-support mailing list