> > 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 here. (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 [email protected] 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 - Choose from over 50 domains or use your own -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
