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

Paul Rogers paulgrogers at fastmail.fm
Thu Jun 3 11:17:32 PDT 2010


> I wouldn't really say they are a "triviality" (given that I am one of
> those who did much of the initial testing/research for the HSR's in
> the first place) but they *are* just one of many parts of the book
> that would need to be checked, though I would argue that they are
> slightly less important than other issues (given how rarely we
> actually have issues concerning them). Package versions must work
> togethers, commands need to be correct, the book's text must be both
> technically correct and readable to those new to LFS, etc...

Of course.  If the package instructions aren't right, whether the HSR's
are correct or not doesn't matter.  But we agree they aren't a
triviality and do need to be checked.  Just seems to me someone would
(have) setup and preserve(d) a trailer system for that purpose.  Guess
nobody ever did.

> Could there be slight variances in "how" one "enters chroot" that
> could possibly affect this? I would't expect that to be likely.

I could post my script if necessary.  But it uses the same template, 100
lines of self-documentation for less than a dozen lines of executable
commands.  ;-)  I suppose I could cut some of that away, if that weren't
to raise questions.

> Well we do mount /proc, /sys, /def, /dev/pts, and /dev/shm from the
> host system.  The glibc build system might be probing something
> like /proc.
>
> Ken's method of first building the LFS target kernel in the host
> system and rebooting to that would avoid potential problems here.

As somebody wrote a while back, getting a config file that was still
compatible with the (back-levelled) host could be a formidable task.
Perhaps I didn't spend enough time on that--lots of new stuff there I'd
never seen before.  It seemed patching up one level was more direct.
When I patched from .17 to .18, I built it as a monolithic kernel and
cut out some stuff, e.g. sound, to preserve the host's kernel and
modules for recovery purposes.  When I get back on that box I'm going to
check again for CC_STACKPROTECTOR somewhere in .18, just to be sure.

> One purpose of LFS (mayhap unstated) is to help the user figure out
> how she got to be lost in the midst of the sea in the first place. She
> may not know where she is, but she should be able to determine just
> how she got there. LFS is, in a manner of speaking, navigation by dead
> reckoning. Everything should work. But sometimes your instruments are
> slightly out of calibration, and one step leaves you 'elsewhere'.
> After that, the rest of the journey is flawed.

I might debate "flawed", by my connotations.  Not recommended perhaps.
But if one can establish where elsewhere is, and where the goal is
relative to elsewhere, one might be able to chart a course to the goal,
and come out where one wanted to go.  It's how some "exploration" is
done.  ;-)  Yes, some explorers are never heard from again--that's why
they post their planned route at the trailhead.  I haven't given-up
trying to get there from here.  Mayhap I'll pickup some disease along
the way, but I don't think necessarily so.  I can boil the water.

> By-and-large, LFS is a great guide. The only real deficiency I've
> found is in the configure options for perl; it took me a week to dig
> through that script (and some source code) to find out why the
> toolchain perl insisted on on needing libgdbm; simply, it was doing
> exactly what it should: build to include all optional features it
> finds on the host. That, of course, poisons the toolchain.

I think deciding on what it "should" do should be based on instruction.
In my case, I don't even NEED nscd, but I'm not given an option, without
hacking one in, of course.

> So, by all means, more power to LFS!

In some senses at least.  ;-)

> > If I'm reading those correctly the problem happens when newer
> > versions of gcc are compiled against an older version of glibc,
> > which begs the question, why was Paul Rogers getting the "undefined
> > reference to __stack_chk_guard" error in chapter 6? At that point
> > the gcc he was using should have been compiled against the new glibc
> > in /tools Or am I missing something?
>
> Nope. I think that's the nub of it. I also think it's a question worth
> trying to answer.

How can I help?  (While I slog on, of course.)  I've got my scripts--it
wasn't all typed in and rolled off screen.

> I agree that the problem you have uncovered is worth pursuing down to
> root cause. Until we understand the root cause, we can't be sure it
> won't come up again in the future. When it is understood, then either
> a prevention in the sense of what a minimal HSR is can be done, or a
> prevention in the sense of a patch to the build can be done.

> No, you do not have to build 6.3 at all. You only have to use 6.3. I'm
> fairly certain that 6.3 is capable of building 6.6, ahd you can use
> 6.3 without building it.

May I suggest that would be true if you had written it "in the first
person."  I believe I already explained how my goals differ than just
producing a 6.6 by any manner possible.

> That's what I said above, and you disagreed with me. Now you seme
> to agree.

How's the old saying go?  "I know you think you understand what you
thought you read, but I'm not sure you appreciate that what I wrote
wasn't exactly what I meant."

> Why do you have this fixation on building 6.3? Nobody but you has
> mentioned building 6.3 as a part of the solution.

I explained that already.  I would say your question would be no
different if it were, say, why someone might self-impose the
constraint of building 6.6 for his i86-64 hardware answering "Why do
that, it'll run the 32-bit code if you just build it as is!"  Before
that path had been blazed, of course.  One either accepts the answer
or it makes no sense.

> If your goal is to get 6.6 running on your machine, then there

Stop right there.  Now who's got the fixation?  You should know by
now that's not true.  I have to do it while standing on one foot and
spinning a plate on my index finger, or some such.

That said, yes, it has already been established I expect I can build 6.3
and eventually get from there to 6.6--but "build" is the operative word.
It's not changing.  Yet.  

Besides, if I continue this path, perhaps it will contribute to
understanding the source of this problem.  If I abandon it and "use"
6.3, what will be learned?  That just avoids the problem, as has
otherwise been the case to date.  Is that not reason to continue?

> is a clear path to do that using an available 6.3 build which can
> almost surely be made to run on your machine. If you insist upon
> using 6.1 to do the build, then I think it is reasonable to say that
> you are partially on your own. I don't mean to say left flopping in
> the breeze.

I appreciate both points.  I finished the gcc build/test in the wee
hours.  Now I'll see if I can get a clean compile of nscd.  It could
get ugly if that doesn't work.
-- 
Paul Rogers
paulgrogers at fastmail.fm
http://www.xprt.net/~pgrogers/
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)

  	

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free




More information about the lfs-support mailing list