*LAUGHS*

Take this man's advice, do what he says, I'll be in the other room laughing at the comedy of the quoting =D

Also, @GrapefruiTgirl, From what I've gathered, your just getting one real "error" with the make check. And that would be:

[testgrp.out] Error 1 ?

It's 'test group' and the error would more than likely be related to an entry in your /etc/group file (as you've already deduced). First off, make sure you have a /mnt/storage/etc/group file to begin with. You should have because that's handled in "4.6. Create Misc. Files". There is also an entry for root with a UID of 0 so also double check what the exact message was for that test. Possibly it's complaining of a different UID? maybe 1000?

I don't build as the user "build", I straight up use root, hence the reason why I never see this test failure. Either way, it's a trivial "error" so don't sweat it. You have indeed gotten a good glibc build if that's the only thing you see. By this point, we should be using "root" anyway in our chroot command as used in "4.2. Enter Chroot Environment", so..... Not sure what is happening there. Either way, it's trivial.

Also, make sure you've seen this part above the 'enter chroot' section:
If you tried to run the chroot command while under the build user or your regular slackware user, it's possible that's the reason. Just making sure you've followed the directions to a tee...

Just noticed that comment..
Looks like you spent a good amount of time on the project. I'll have to admit, it's a good idea. Been seeing comments about it for awhile but haven't looked into it yet... Scripting an automated build using src2pkg would defenately put it thru the grinder... Not sure what that would entail at the moment, as I haven't develed too deeply into src2pkg, but it would be a good endurance run...

@ jong357 - yes, that was indeed the error I was getting, the testgrp.out error, and when I checked the file itself, it was complaining about two different things to do with the /etc/group file. *IF* I get that again, I will disregard it. The (ignored) error is to be ignored as per the docs.

Currently I am moving along with a completely fresh run of it all, and am at gcc stage 1 now. I'll check back in when I arrive at the chroot stage, before I install the man pages, because I may have another question or two about installing & using pkgtool -- I was getting fairly stymied while trying to get that $PM_DEST thing working as well as even getting pkgtool installed to start with; the Slackware pkgtool package is made of a bunch of pieces, patches, etc, and also, it complains about my using tar 1.16 and tells me I should be using tar 1.13. Well, tough if I can't get pkgtool to install/work reliably, I'll likely use src2pkg after the system is running on its new 'engine' after all this is done.

On that subject, I did a fairly large run of packages of all shapes and sizes with src2pkg last week, and I gotta say, it works like a charm. Infact, with a few little tweaks/some support scripting around it, it is almost a package manager in itself so again, kudos to gnashley for that,and thanks. Perhaps it's fair to say, a gruelling test of src2pkg will be making glibc with it

OK, back in a bit

PS - OH! And know what? On the subject of the /etc/group file errors, it's doubtful my kernel header choice is causing any troubles, so I think I'll just go ahead with 2.6.21 as I had to start with.

Yea, I know what your saying. I find pkgtools on slackware to be rather choppy myself. That's why I spent alot of time restructuring it on my file server. My script may or may not give you some guidance.

http://jaguarlinux.com/pub/DIY/sourc...pkgtools.build

Probably my biggest pet peeve is to split packages up when they really belong together (look at my python script :-). Before I started using debianutils, I had mktemp a part of pkgtools as well. Now I just have dialog, tar-1.13 and pkgtools. There is a reason why tar-1.13 is still used altho it may not hold true anymore with tar-1.16.... tar-1.14 and 1.15 will screw up your symlinks in the doinst.sh... Thus, the reason why "tar-1.13" is hardcoded. You could remove that check if you feel like testing your luck.

As long as you comment my 'jag' patch in my pkgtools build script, you should get the stock slackware-11 pkgtools... Oh, change desc to slack-desc at the bottom too. A slackware(based) system without pkgtools is like cereal without milk... You might want to reconsider... Really, any system without a package manager isn't worth much IMO... Too difficult/near impossible to maintain.

Also, if you don't mind killing another hour/try of glibc, build it the first time with the DIY /etc/group file. If you get a test failure again, edit your group file and change it to this:

root::0:root

then try rebuilding to see if you get the same error... Even tho the test failure may not be all that important, it could still indicate a possible problem with your system... Just depends on how anal you are I suppose.

If you still get an error and want to waste another hour, bust open my etc-5.0.tar.bz2 tarball and try using my /etc/passwd and group files. If your STILL getting that error then I haven't the faintest idea what's happening... :-) Or you could just use my 2 files the second or even first time around just to see right off the bat whether or not there is a problem with your etc files...

ALSO, try running your make check command like so: make -k check >glibc-check-log 2>&1

Then when it returns you to the prompt (there will be no output) do this:
grep Error glibc-check-log

Thanks Jong357, I gotcha on all points in your last 2 posts, and also I have already been tee'ing the output of the glibc builds to a file which I grep for errors, which is where I have been looking at the results.
I wrote gnashley with a question or 2 about src2pkg, as it uses pkgtools as a back-end, to see if he thinks it will run in my semi-built environment. If it does, and if glibc builds right, then I may delete it and build again it with src2pkg.
Anyhow, in about half an hour, I'll be at CHROOT again, and building the glibc for the make & make check. I'll update then. BTW I made not of your info about the passwd and group files and may take you up on the offer of your files to try it out.

Basically I am doing much of this the same as yesterday, as the overall succes rate was very high; except I am building in my home folder (as user 'build') rather than on a separate partition. That was giving me grief because the symlink from the new partition to my host root partition was preventing me from unmounting my partition and rebooting cleanly

SV

GrapefruiTgirl: What a thread you've started ! ---- I wonder if PV ever looks in and smiles to himself ?

Gotta be said to all you 'Slackware from Scratchers' this is educational stuff. I started along the LFS route as a side project a little while ago with the intentions of getting to know how a Linux distro works from 'ground zero'. All this excitement has prompted me to have another go - (given the insomnia that this creates) - however I am doing it from an LFS 'live' CD saving work in progress to a spare mount point on one of my Slack boxes. My save points have just got messed up and i have lost 20 hours of work - sh*t.

So what do I do ? Reboot to my shiny new Vista installation - (dual boot, please don't hate me people) - to further another of my educational projects - setting up w2003 server with AD (yes I know I swore but I am trying to broaden my bill-paying knowledge to fund my Slack addiction). Oops - now there's a surprise - Vista Home Basic can't connect to a domain controller - what !!! I need to pay M'soft another £65 for the privilege. I rarely boot to Doze these days but need to update my skills in these technologies. .... Sod it - all back to Slackware - I'm gonna try the path you are following (and all credit to the other posters for all their sage advice re: LFS/Jaguar/DIY/etc/Slamd/etc). Does make you think though - that Patrick chap is a bit sharp !!

BTW: Hope you have been logging your findings as this stuff will be useful to a lot of people - not least me !!

Can't wait to see the outcome of this one

Tell ya what, I agree: Pat's a brilliant character -- and I really do hope he takes pleasure in the pleasure that 'we' take in his masterpiece, in all it's forms. Mustn't neglect Linus Torvalds either -- without his initial genius, where would we all be now? I don't want to imagine...

Someone around here has a signature to the tune of "Linux is a very simple system.. But it takes an absolute genius to see just how simple it is!" <-- and quite true. I mean, all these damned cryptic shell commands and stuff, but WOW - the power and functionality of these little same cryptic tiny little commands. It amazes me. And furthering my amazement at the creation that is Linux, is going step by step through this process of building the thing from the ground up (yes, even though someone else wrote the code) and watching it 'create itself'
How cool is that? Is there another (operating) system that can actually do this?

Bgeddy, I'm happy you have been inspired and hope others are too -- remember everyone (newbies and all), I started using Linux in DECEMBER 2006!! So don't give up; you CAN figure it out and have a great time with it.

NOW - lol, back on track: I just manually installed pkgtools and src2pkg, so now, as I am just about to build glibc again for the first time today (been a busy day) I am going to see if I can't make a package out of it too cross yer fingers, here I go!

Wow.. I just spent a totally &%$#@*&$#@ inordinate amount of time farting around with trivial, annoying, weird stuff, while doing final preparaations to build glibc (which you'll recall I was about to do HOURS ago )

jong357's posts of a few pages back have been invaluable regarding the package management, and I am really glad to have finally gotten it sorted out, for the most part. Here are a couple details:

1 - pkgtool doesn't like tar 1.16 so to use pkgtool I had to install tar 1.13. trouble was, in CHROOT, tar 1.13 didn't seem able to unpack bzip2 archives, which half of my source tarballs are. So, I reinstalled 1.16, but it wrote over 1.13 so I had to reinstall 1.13, and then install 1.16 as "/bin/tar116" and use it specifically if/when I need it. I install pkgtools by hand, so had to also install 'dialog' and build & install 'mktemp' as well

2 - Time to install the kernel headers, once I got the pkgtools fixed. Same headers I installed about 2 dozen times now, but OOPS - LOL suddenly they wont "make check".. "Error - version.h does not end in %" which it took me about 1/2 hour to determine that my /dev/null device had gone AWOL at some point, and wasn't dev/nulling properly. I made a new one and the headers finally checked out and installed fine.
Except for that I had to do it about 6 times because I had the PM_DEST short one level, so the damned headers kept installing to /include rather than /usr/include .. Whew.. This made the glibc './configure' quit because it told me the headers were either non-existent or too OLD!

So, this mumbo jumbo has consumed the past couple hours at the very lease, what with unpacking, installing, deleting, re-unpacking, re-installing, deleting...... I think there were almost 10 GB in the trash bin but --- glibc is building as I type this and if I can stay up for a bit, we'll see how it goes.

OK, well here's the only two errors resulting from 'make check' of glibc-2.4. note that they are BOTH different than the errors I had yesterday. NPTL I believe is 'linux-threads' which as I understand is no longer supported in some version of glibc. But what is it?
Also worth noting, the two files highlighted here are both empty which maybe is a good thing?
I went into the build directory and ran each test alone several times, by itself, and >> to a file, and no output at all to the files.. Not sure what to make of it.
from : http://nptl.bullopensource.org/Tests...NPTL.html#nptl

and..http://cvs.savannah.gnu.org/viewvc/libc/libc/nptl/ shows a bunch of undecipherable crap about both tests

I'll run it all again tomorrow after maybe seeing if you guys have any input.

sleep time..

Ooops! Forget someone? Initials: R. M. S.?

WahoooOOoOOo Check this out:

No Errors

Here's a tip, which I think solved my problems, and which (jong??) suggested, as well as I read about on one of the cryptic mailing lists:

The host system DOES play a part in the build of glibc, ESPECIALLY the overall system load, while building and testing the build of glibc.
I paid particular attention to the CPU load in 'top' while running the test-suite, and on tst-cond17 which failed yesterday, the CPU load was around 98% and the test alone takes about 20 or 25 seconds to run.
When I ran the test yesterday, I had Ksysguard, Firefox (about 10 tabs open), Konqueror ( several windows and tabs) as well as likely a few other things, PLUS a couple memory-hogging old hung tasks lying around in the background.

So today, I made-clean, made-tests-clean, rebuilt glibc using CFLAGS -O2 instead of -O3, opened Ksysguard as root and killed off a bunch of stuck-in-the-mud processes, then closed everything off except the glibc build-console and 'top'. The thing compiled a good 20% faster than it did yesterday, AND the test suite ran faster and completed error free !!

Well, I got off to an early start today, and now I want some breakfast!

Happy day everyone!

Oh, BrianL - I didn't want to say anything and reveal my initial "drawing a blank here" predicament but Mr Stallman is absolutely to thank as well, and for those interested, check out his very interesting website: http://www.stallman.org/

~ Sasha

Things are looking good. Got my fingers, toes, & everything else crossed for you (very painful!). I'm sure Mr Stallman will forgive you.