OK, thank you, that little part was most helpful!
Yep, I realize this.
Good point! Though all things considered, I don't depend 100% on the Slackware package manager as it is now. Still, good point.
Please do not think I am taking the errors lightly. I am not. If I were, I wouldn't be on my fourth complete cleanout/unpack/make/make-check of glibc. I may not have absorbed every drop of info I have perused the last few days, but one would be hard pressed to miss the large WARNINGS and pointers to Ulrich Dreppers rant about installing glibc. Incidentally, I now know the [Error] *** make was apparently caused by a missing ':' in my /etc/passwd file, thanks to the GNU-glibc mailing list. I'll have verified or disproven this shortly..
I DID infact create the temptools, tarballs and patches directories, as well as following EVERY line of the .bashrc/config.site/bash_profile section, and all that stuff is just fine. My time zone is set correctly as America/Halifax. SYSROOT is perfectly correct.
I really appreciate your help here, and that of others, but despite having read all the docs (and I'm still reading while I am compiling) there are subtleties missing from DIY AND LFS documentation, which you are being very helpful in making me catch onto. I wish though you would leave it to me to trash my system if that's what happens, and meanwhile, please don't assume I am blindly plowing ahead with no clue. There would be no point going to all this trouble, if I were carelessly leaving half-concocted compilations in my wake which would forever be unfixable. The point I admittedly DID miss here, was that I am still supposed to be using that 'tarballs & patches' arrangement DURING the chroot phase. Thank you once again for clarifying that for me .
I thought I was relatively clear when I started this thread but the purpose of this whole experiment, besides teaching myself something about the guts of Linux, is to wind up upgrading my running Slackware to a Slackware that's more current (GCC 4/glibc 2.4), that's optimized for my machine (i686), so runs a bit faster, and which was compiled by me
As mentioned, I'm not "blindly" doing anything..
I have the Jaguar site open, have had since yesterday, but again, going back to the build-order, that makes THREE different build orders, so yes, I guess I am leaning towards the DIY method.
Again, thanks for reminding me/telling me to start up pkgtools at the chroot stage. You got me just in time for that -- kindly remember, there's no mention of pkgtools, or when to install them, in the DIY, as it IS DYI after all, so I definitely would have missed that opportuinty. I had planned on finishing the toolchain and base build, and THEN when the actual 'real' system was up and running, to start re-packaging the rest of the Slackware packages.. Your advice on that is welcome.
As for what versions of this and that are in the next Slackware release, and not knowing personally when it might come out, I will just have to apply what I learn during this process, to my next rebuild, at which point I may go to glibc 2.5 if it has proven stable and compatible enough, or who knows maybe by that time I'll be way off on a tangent from "Slackware" as we know it!

Well, I'm sorry. Didn't mean to come off condecending or anything. I just hate to see you spend so much time on it and then realize you should have done this or that in the beginning. Greg (of DIY) isn't big on spelling things out all that much so, yea, the docs don't go into great detail about certain things. He uses pacman from Arch Linux, so that's why pacman is listed in the temptools section. You are meant to install your package manager of choice before you start the chroot stage...

As for where to keep your tarballs you can put them anywhere really. I allways keep them in /mnt/storage/source. If you come across something that needs to be patched then adjust the DIY patch command so it's right...

My build order should match DIY's precisely except for the addition of file, mktemp and berkley-database... Haven't double checked in a few months tho... Oh.. I also added xfsprogs and udev at the end... Maybe one or two others because I consider them to be a "base" package...

Well, again... Sorry if I sounded snippy. It's just really frustrating getting towards the end of a couple day project, only to realize you forgot to do some key things... You can still make packages of everything in the chroot stage that you didn't originally (if you've gotten far). As long as you haven't done the 're-adjusting the toolchain' section doing an 'installpkg' overtop of an existing glibc shouldn't hurt anything. It's once you re-adjust the toolchain and actually start using your final glibc is when your bound to it.... Then, you would have to make a package like Slackware does, that's able to 'upgrade' overtop. I don't do this for my glibc package, so what I do is boot into my live CD, mount my partition (but don't chroot) and use "upgradepkg ROOT=/mnt/jaguar glibc.tgz" (I keep pkgtools on my live CD). Otherwise, running my 'standard' doinst.sh for glibc will really break a running system....

Anywho.... Keep us informed...

No worries, I appreciate the reply and your continued input.
Now that I have gotten this far, and have enjoyed what I have done so far, I fear I may have to start again anyways: Something just simply is not working with the second compile & make check of glibc.
I can't track it down to one single thing. I've re-done it from scratch about 5 times, at about an hour in total each time to config/make/make-check, and still it ends the same way. The LFS tutorial explains the (ignored) message as being caused by the host system, and is not important. The second error, I can't figure out.
The 2 repeated errors every time at the end of the check run is "posix/<something> (ignored)" and "tests/grp<something.out>" -- apology for not having the exact errors handy, I have long scrolled them off the screen.

There are mixed messages in the mailing lists and on GNU/glibc.org about whether the 2.6.21 headers, will work a) with glibc 2.4 b) gcc 4.1.2 c) on my machine, and d) with my running 2.6.21 kernel, due to as-yet unknown bug(s) so even though I don't want to, I might try the 2.6.12 libc headers as a test. If the problem goes away, then it will be safe to figure it's the headers causing the problem, at which point I will again try the 2.6.21 headers (lol <-- sucker for punishment).

I don't look at this as a setback because I have learned a whack of stuff, and when I start tomorrow it will get back to this point quicker than it took to get here now, thanks in part to your input and other users filling in some of the grey areas in the DIY tutorial.

Thanks again jong357 for the help -- I'm not going to give up But I hafta go to bed now
Update tomorrow when I get to the chroot again!

Your RUNNING kernel plays a HUGE part in the success or failure of building glibc... Headers built against shouldn't be too big of an issue. As long as they are 'recent' 2.6 headers... I think I used a 2.6.18 kernel and headers (unidef patched) when I built glibc-2.4 using gcc-4.1.1 (slack-11 host) and I had no errors what-so-ever. I did get an error that was due to an option compiled into my running kernel. I removed that option, rebuilt the kernel, rebooted and then re-chrooted and the make check passed everything.

While the make check is important, don't get TOO hung up on it. I don't wan't to contradict my earlier statement, but.... I've used glibc-2.5 that had about 20 locale failures, 4 math test failures and numerous other make check failures.... I didn't feel too good about using it, but it seemed to be working as it should with no visible problems...

Try opening up the file in question that failes.. If you don't get a clue to what is happening, try googling for the contents of said file. You might get lucky and find a solution to ditch that error... If all else fails, you can't seem to ditch the error, and it's only a couple errors, then just keep going and use the resulting glibc package... 10:1, you'll probably be allright.

Interesting stuff regarding the running kernel and glibc - I've never given that much thought since mostly I deal with cross-compilation where clearly my running kernel isn't even the same architecture =) I do not want to confuse the issue by sticking my oar in, so I shall try and keep this short!

Anyway, I was just about to say "Whoah, wait, surely that's not true?" (RE: running kernel being important) when I found some interesting posts from the DIY mailing list. Maybe you've seen them, maybe you haven't, but here they are for the newcomers to this thread:

http://sources.redhat.com/ml/glibc-b.../msg00029.html
http://www.diy-linux.org/pipermail/d...st/000847.html

And fwiw, you only need a very bare compiler to build a kernel (the kernel runs at system level, which means no C library functions to call on, thus no glibc required!), so I would concur - GCC-Pass1 is kernel build time if needs be. And at the risk of looking like my oar is being stuck in, worth reading up about the whole "kernel" vs "kernel headers" and even "sanitized kernel headers", hopefully you'll be able to spot the running themes with building the toolchain across the different build methods (DIY, Jaguar, LFS, etc) and understand the difference between "kernel source" and "kernel headers":

http://ecos.sourceware.org/ml/libc-a.../msg00162.html

I shall be watching with continued interest =)

Best regards,
- Piete.

Edit: the answer to "Whoah, surely that's not true?" is "sometimes", or more accurately "depends how you build the system" *sigh*

If there was a poll for the "Most Interesting Thread On LQ", this would surely deserve to win.

I may actually do something like this myself.

I love slackware, but i386? Reason why i went to arch linux really.

If this does work, please post up

Do you reckon I could arch optimise for x86_64 from the i386 installation?

I make the assumption you want an x86_64 system, not a well informed x86 system. x86_64's native 32-bit instruction set should be i686, but I cannot find any links on the AMD site that state this explicitly to back up this claim. I don't know what AMD specific extensions (SSE, SSE2, MMX, etc - http://en.wikipedia.org/wiki/X86-64 has some info on this) the chips have or how important they are, on balance, to an average (a real abitrary notion!) running system.

Regardless, "x86_64 optimisation" would be best done by recompilation of the whole system using a cross-toolchain, which I think is out of the scope of this particular thread (because cross-compilation is very different to arch optimisation at the build level in technique) ...

Anyway, some threads that have looked at this in the past:
http://www.linuxquestions.org/questi...d.php?t=433767
http://www.linuxquestions.org/questi...d.php?t=339819

Some of the information I put up is a bit out of date and could be misleading - messageboard posts are worth exactly what you pay for them - so always do some reading around the topic!

Good luck,
- Piete.

Would you just suggest using slamd64?

But I thought this want that supported...

Personally, I like slamd64 and think it's brilliant. Some people have problems with it (geniune bugs or seat-to-keyboard errors).

In the end, try it and see it. Like i keep saying, most of the time the problems will be slackware related more than slamd64 related, but there are a bunch of gotchas in compiling that are worth knowing about (./configure --libdir=/usr/lib64 --prefix=/usr being the most common, imo).

Would that give better performance then turning i386 into x86_64 ?

I'm sorry, could you restate your question? i386 --> x86_64 is the same as slackware --> slamd64 .

./configure --libdir=/usr/lib64 --prefix=/usr in i386 will not optimise anything, it was an example line for compiling into a bi-arch system.

Ok, I understand, I think im just going to run Slamd64.

(Sorry for breif hi-jack)

Quick update while I make breakfast here:

I did the above, and the first time, there was something apparently amiss with the /etc/group file, and the second time it told me that it couldn't find a user with UID=0 which both to me are pretty insignificant, however, this being a situation where I want to eliminate ANY chance of self-induced correctible errors, I'd really like to see ZERO errors on make check.

I think I AM using 'fairly recent' 2.6 headers, ie: the same ones I am running on the host -- 2.6.21. I have 2.6.20 here too, so maybe I'll try that first rather than downgrading to .18 or .12.

Also, I think I'll script the initial package builds so when I need to do this again from the VERY start, the first half will 'do itself' and also, I'm gonna set up the unpriveleged user account FIRST, from my desktop, rather than from the console during the environment setup, so I can hopefully get him allowed to use X and thus MC and Konqueror. Not sure how that will work, but gonna try.

OK, looking forward to getting started, but dishes and breakfast are first on the list.
Have a great morning everyone; see you soon.
SV

Yea... I've seen them.. I'm "Jon"...