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

Paul Rogers paulgrogers at fastmail.fm
Thu May 27 09:22:13 PDT 2010

> > make[2]: Entering directory `/usr/local/src/glibc-2.11.1/nscd'
> > make[2]: Leaving directory `/usr/local/src/glibc-2.11.1/nscd'
> > make[2]: Entering directory `/usr/local/src/glibc-2.11.1/nscd'
> >
> > gcc nscd.c -c -std=gnu99 -fgnu89-inline -O2 -O3 -Wall -Winline -Wwrite-
> > strings -fmerge-all-constants -fno-stack-protector -g     <---- -
> > march=i486 -mtune=native -pipe -Wstrict-prototypes -mpreferred-stack-
> > boundary=2 -DIS_IN_nscd=1 -D_FORTIFY_SOURCE=2 -fpie
> -fstack-protector  <<-- overrides earlier setting
> > -I../include -I/usr/local/src/glibc-build/nscd  <----

Yes, that's what the arrow just above noted WHEN I composed the message,
before it got reflowed.

> After you get to this stoppage, try doing a paste of just these
> instructions back with modifications.  To do that, you need to paste
> into vim and add backslashes to each line, change what you want
> (delete -fstack-protector) and see if you can get that one file
> (build/nscd/nscd.o) to build.

Yes, I can try that, but to what aim?  Presumably (I'm out of my depth
here) that means, at best, when make was rerun and discovered this was
already compiled then I'd end up with a vulnerable routine in my Name
Service resolution code without SSP.  Although the versions I run daily
now have NO SSP at all, still I'm not sure I'd be entirely happy running
with that known flaw.

Would compiling this with -fno-stack-protector successfully somehow lead
to diagnosing a way to recompiling again with a protected version?

>  Hmm, I can see you don't like updating kernels ;)  Assuming you can
>  get past the current problem [ for that, my only advice would be "try
>  a newer host" ], you will be in for some *serious* fun in

Is this where I flip the kimono aside and reveal I do have a LFS-6.3
LiveCD (from LXF) available?  I REALLY didn't want to go that route!  I
first made LFS-4.1 (POD-1.x).  Used that to make LFS-6.1 (POD-2.x). Then
even got a CD of 1999 vintage code and used the same process to make
something like a LFS-(2?).? (POD-0.x) for my 486 that runs every day
(Something I expected that 486 to run when I bought it new.)  I really
want to have a continuous upgrade path--without a discontinuous "then
magic hocus-pocus happens" step.

> getting from a .config that worked in 2.6.18 to one that works in
> 2.6.32.  Particularly, libata [ most ide drives now use libata and
> therefore /dev/sdXn instead of hdXn ].

Yes, I've seen that in some of the other distros I've gotten from LXF.
Using SCSI emulation for IDE drives just seems WRONG somehow.  I'm a
follower of Einstein's dictum, "As simple as possible, but no simpler."
The systems I'm building on/for (P3's) all use PATA drives, and I was
hoping to deal with SATA later in a POD-3.2 version.

Presuming I can get beyond this stack-protector problem, of course.
Guess I'll try Bruce's suggestion above, though I don't know what
would come next to resolve the issue.  The script's I've hand built
from the books, with additions like piping configure/make to tee 
capturing the console listings, give me a reproducible build process
ala ALFS, and this kind of thing isn't scriptable.
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 - Choose from over 50 domains or use your own

More information about the lfs-support mailing list