Tell me about it... I barely have the patience for a new build when everything goes right. I would have put my foot thru the monitor along time ago if I was her...

LFS is preferable for first timers. Not as technically correct IMO but easier to grasp. After a couple years of LFS I think it's only natural to loose interest in it and go a different route. Once you utilize LFS for it's 'teaching' aspect, it really becomes nothing more than a copy/paste exercise... Pretty boring... AND no package manager...

Now, GrapefruiTgirl, I hope your not starting over each time at the beginning. Your /temptools seems sound so no need to keep re-doing that. Also, since your using pkgtools, it's trivial to remove a "crappy" package and just redo that particular one. With the exception of glibc ofcourse, but we already talked about that. If you've readjusted your toolchain AND want to redo glibc AND are still at the beginning of 'chroot', then I suppose it's best to just start over at the beginning of 'chroot'...

If your system is already up and running AND you want to redo glibc, then re-visit gnashley's post concerning glibc and adjust your build method accordingly..

Gnashley, I'm interested in the problems you were talking about concerning the ROOT variable and installing to a mounted partition. As I've said, I'm not a big believer in upgrading glibc but I have done it once or twice. I never noticed any problems with using the ROOT variable pointing at a mounted partition. When I reboot into that system after 'upgrading' glibc, everything ran fine... It did make all it's symlinks in the correct partition, atleast as far as I noticed but I wasn't looking since everything was working...

Well, sometimes I just go back to the start and set the environment up again, and other times, after I've lost complete track ov where I am, I wipe it and start fresh.
The damndest thing with the Slackware aspect of it, is the bloody package management. Seriously, if it weren't for me trying to get that accomplished too, I swear I'd be done this thing long ago.
Anyway, I have a nice script that accomplishes the whole temptools part in around 1.5 hours without my help.
Currently, I'm re-scripting the chroot-onwards stuff to use 'some' makepkg but mostly Src2pkg. Src2pkg complained about my CFLAGS, so I had to rewire src2pkg a little bit.

Once in chroot, Pkgtools won't work without ncurses, which doesn't get fully installed till way later. Also as we discussed, pkgtools AND src2pkg both want Tar-1.13, but with the path changed during chroot, tar-1.13 isn't around, so it complains about tar-1.16. pkgtool also wants 'Dialog' and 'Mktemp', neither of which are on the menu, so I install them first (after MAKEDEV), inside chroot.. Now I find out that src2pkg is looking for an obscure little BSD tool called 'rev' which I am about to locate.
Anyhow, for anyone crazy enough to be interested in trying this with Slackware, the solution is to dump all these packaging-tools-dependencies into my TARBALLS area, and add TARBALLS to the beginning of my $PATH. There's nothing really important or critical in there, like big stuff needed to build the system, so unless I'm specifically running a command (script) which is packaging something, the whole DIY bit just ends up on the regular path. I'll hafta put together a 'chroot-package-#1' of packaging stuff that is needed to make the Slackpackages when the host tools are unavailable.

I'm really happy with how the scripting is going; but, I am painfully, almost obsessively compulsive when it comes to detail, and somewhat of a perfectionist, so this might be the 'tidiest' bunch of code you've ever seen, once I'm done. I'm pretty fussy.
Wellll, I'm glad you folks are all hanging around too and I thank you for your interest, help, and patience.
Back later

Something is wrong with your environment then because the ncurses in /temptools should be used right away. Do an 'echo $PATH' while your in chroot. If your not seeing /temptools/bin at the very end of your PATH then something is wrong.

Same as above

Build those at the very end of 'temptools'. Then the same thing will apply as above.

No, add it to the END of your PATH. This is the way /temptools/bin should be, so when we start installing packages in chroot, our brand new ones will get used instead of the temptools ones. The PATH is searched in order so we only want /temptools/bin to get used as a last resort.

At the risk of sounding like a broken record, same as above. Just use /temptools/bin..

Yea, that's ussually the whole reason why people do stuff like this... I'm the same way. I bet you get bent out of shape if someone puts your dishes away in the wrong place or folds your laundry different... Right??? I annoy the piss out of people with stuff like that, especially at work..

GrapefruiTgirl, be sure you are using the latest src2pkg from here:
http://distro.ibiblio.org/pub/linux/...nload/src2pkg/

src2pkg-1.3 detects your tar version and adjusts the arguments accordingly. Also note that there is a whole bunch of new html documentation which may help you.
What was the problem with CFLAGS? And what did you do to change it?
I suspect that you haven't gotten the hang of how all the various variables get strung together to create the final CFLAGS string. But still, for what you are doing it really is much better to take things into hand manually inside your src2pkg script for the package, by commenting out the functions for any or all of: configure_source, compile_source and fake_install. You can even use the 'make DESTDIR=path install' method by using this:

cd $OBJ_DIR ;
make DESTDIR=$PKG_DIR install

The rev program is part of the util-linux package.

I turned my eye a few months ago to doing exactly what you want to do, that is, recompile and optimize the whole system, making packages as I went and trying to work out a way to script most of it. This inspiration has driven some of the recent additions to src2pkg, such as handling of URL's for multiple source files and the problems of running with a very limited system, including the 'tar problem'.
I actually found a pretty comfortable way to accomplish this even without any chrooting. This is only possible because the basic programs for the system don't care about the compiler libraries which are architecture dependent. For Slackware these are in /usr/i486-slackware-linux. When you optimize these will be located in some other target/host directory like /usr/i686-grapefruit-linux (or completely generic: /usr/i686-pc-linux-gnu). Most C programs do not care at all about these libs at all -but binutils and gcc do. (you could have a second compiler which uses the same glibc but has separate binutils for itself).
What I mean is the toolchain is only binutils and gcc -everything else you are dealing with (bash, tar, ncurses, etc) is only worried about what's in /lib and /usr/lib. The old binaries will usually still run under the new libs while you go about recompiling them against the new libs -I did this all from the comfort of X and only needed to reboot a time or two(once I worked it all out, mind you).

Compile a static package of binutils (--prefix=/static/gcc)
Compile a static package of gcc (--prefix=/static/binutils)
Using the new versions you want to end up with above may cut down on the number of passes.
Compile a new kernel using the static tools created above(PATH=/static/gcc/bin:/static/binutils/bin:$PATH)

Reboot running the new kernel.
Compile the new glibc using the static tools(same PATH as above).
*Install* the new glibc to / (or install to a DESTDIR and then add the DESTDIR path to ld.so.conf) and then run ldconfig.

Compile the new binutils (not static) using the same static tools and PATH as above(--prefix=/usr/i686-grapefruit-linx): (PATH=/static/gcc/bin:/static/binutils/bin:$PATH)
Install the new binutils(don't forget to remove the old ones)

Compile the new compiler (not static) using the new dynamically-linked binutils and the old static compiler:
(PATH=/static/gcc/bin:$PATH)
Use (--prefix=/usr/i686-grapefruit-linx) but create the links to /usr/bin
Install the new compiler.

At this point you have the new toolchain running and can advance to re-compiling everything else, but it's probably better to go ahead and recompile these 3 again in the same order and use this build to create your packages from as they should finally all appear to have been compiled dynamically by/against/for each other.
Then rebuild everything else observing proper order and other circular dependencies such as with bash gettext/ncurses, etc.
As far as I can see there should be no problems using src2pkg at this point for rebuilding all packages.(I am unsure when/where you are first staring to use it and as to whether src2pkg will work correctly in a chroot environment)

I'm going to work on a scripted method for doing the above since it relates to (and shows off) features of src2pkg. Your feedback is helping me to accomplish this.

The above method implies that you want to upgrade or cannibalize your currently running system. A little further work could produce a (more gentoo-like ?) build where you start with a static toolchain and a few other static programs like init, bash, make, sed and using busybox for most of the other basic essentials(busybox sed may not work). This basic runnable system could then be untarred onto a new partition and then booted to build an entire system from sources.

I really hope I'm not confusing you -I'm sure you have a headache from all this. I get one just thinking about it...

Nah -- not a headache from all that, but I DO have one now from the recovery operation I just finished :/

I didn't have a satisfactorily recent backup of my latest tweaks, so after another errant "rm -Rf /*" due to a $TEMP2/* which should have been a $TMP2/* I shut off the machine, loaded knoppix, installed 'recover 1.3' and undeleted everything that HAD been in my /temptools area - to the tune of some 80,000+ files :/ :/ :\ and scripts, all I wanted back was my most recent script pieces ( about 9 files ), but got everything.. Oh well.
Anyhow, just finished sorting out what I want and re-deleting all the rest, and prolly not gonna get much done tonight.. Never know, I'm kinda a night owl...

Gilbert, the main thing src2pkg was jamming up on was '-march' or '-mtune' I can't remember which, but when I looked through your FUNCTIONS or DEFINES, whichever it was, I noticed the gcc version check, and some other stuff there which for some reason gave me "Unknown option", and so basically commented out the entire CFLAGS/optimization section of your code, because also, it was conflicting with my environment variables, which also defined CFLAGS, heh heh, so I was getting everything TWICE too.
Either way, I am finding src2pkg a WAY more versatile way of doing **some** things, but other times, makepkg is the way to go.

For example, I couldn't get src2pkg to build and install the kernel headers. No matter what I told it to do, it would quit telling me "No target to make 'headers_install'" yet if I manually typed 'make headers_install' it would go just fine.
I'll try to give better details as I move along; I haven't necessarily 'documented' every 'glitch' I come to, but rather work around it first, then ask questions later

Now, I dunno about what "might" be wrong with my host system $PATH, because I have no problems with it on a daily basis, and I DO have the path correct inside chroot. But the path seems such that when an application is looking for something, it takes the path, and uses the first <tool-name> that it finds on the path. I HAD temptools/{bin|sbin|usr/bin} in my path, but it wasn't sufficient for some things.
As one of you guys mentioned above, installing MKTEMP and whatever else should do the trick..
It's like a chicken and egg situation: I need A but A needs B first, but B needs C but C needs G but G needs A --- a circle of dependencies, like when your phone's broken and someone tells you to call the repair guy :/ ..

As for ncurses not working, I dunno.. It works outside chroot, but inside, pkgtool won't work, DESPITE the fact that when I watch some ./configure scripts scrolling by, they DO often list "Checking for ncurses: yes (ncurses)" or however it's worded; so it IS there, but pkgtool can't find it (go figger)
LOL anyways, enough rambling.. Back later

PS - I do have src2pkg 1.3, built it myself from the sources, but it still complains about the lack of tar-1.13. Ultimately, I'd like to say that whatever it is within pkgtools that has it bound to tar-1.13, should be fixed. That's just IMHO, but why need two tars otherwise :/ when 1.16+ does so much more.

LOL

That does tend to happen quite a lot when building from the ground up. It does get tricky, but there is a way to resolve it ... well, otherwise, I wouldn't be here typing this

(and it also happens often in distros with "dependency resolution", like RPM and DEB distros ... I've had this happen a lot, mostly due to broken packages, and sometimes they were unresolvable, you had to kill either the chicken or the egg to stop the cycle)

A good guide typically resolves these types of issues (if you can find one, of course).

OK.. Yes, I found 'Rev' after a little hunting; not much to be found on the net about it, except the rev man page. DOesn't even say where the tool comes from, but I found it after a bit of guesswork.

I know about the static-compiled toolchain concept, but it seems I prefer doing 'some' things the hard way and so forward I march towards an end somewhere in the near future!

To prevent further headaches, I'm gzipping the whole BUILD folder before any major test runs from now on, though I must say, if anyone doesn't know about 'recover 1.3' and you want to know how to un-RM files on Ext2, that's the way to go. Awesome!

OK, Anyhow, I'm back at it here, ready to run thru the first script in the chroot phase which will end with glibc installed and packaged (hopefully) and the system files (nsswitch etc..) created.
Here goes..

PS - Yes, I HATE people doing my laundry; I seriously detest it. It isn't necessarily the folding, but the actual washing itself; no one does it right . And I'd rather was the dishes myself too

So I'm browsing using 'links' browser for the heck of it. FIgured it would be kinda neat to try it out. I like it . It's fast for sure..
So anyhow, all is going very well; I was indeed still having some issues with my package managing (solved) AND that gcc 'myspecs' file, which I have now been putting into its own tmp folder . Glibc built and tested out perfectly, and gCC built after that, with no problems.
SO, my question of the day: How much variance is acceptable in the gcc test-suite results, from the reference on gnu.org?
My results are EXACT for "g++ tests", "g++ Summary", "gcc Summary", and "libmudflap Summary". The questionable one is "libstdc++ Summary" -- I have 3350 out of 3390-odd expected passes.
SO, what exactly is 'libstdc++' and are these results ok? Should I try fixing this? Hmm..
As always, input is appreciated

libstdc++ is probably the standard c++ library ... needed to compile c++ programs.

As long as you don't see any "unexpected failures" then don't worry about it. 9 times out of 10 you'll never get the same results with the ones listed on the gcc mailing list. Even 'unexpected failures' can be trivial sometimes and ignored. As long as they are close, then don't sweat it.

Then I suppose this isn't too good then.
Well, last time I ran all the tests, it scored perfect. I think that since I've got the scripts working up till this point, it should be a minor deal to rebuild gcc again and try the tests again.
Thanks, will update later.

Remove -mtune and try again. Just a hunch so sorry if it has no effect.

Yea... You shouldn't have that many unexpected failures. 1 or 2 I could live with but any more and it indicates a problem IMO.. Altho, it's still possible that build of gcc will work perfectly fine. Hard saying without knowing what tests failed and why.

As for the -mtune option in general, it's really kinda pointless to use anyway. The only reason you should be using mtune is if your distributing your binaries to other people to maintain compatability with other arches. As far as I'm aware, that's the only use for that flag. So, having said that, using -march=i686 -mtune=i686 is redundant. I forget what mtune your using but that's just an example. So, try ditching it and redo gcc. In the case of 3.3.6 for your cxxlibs-5.0.7, it'll completely crap out with mtune (becuase it doesn't recognize the option).

In fact, glibc-2.6 seems to be really finicky when it comes to the CFLAGS you use. It's probably best to get in the habbit of stepping it down a notch and just try to use CFLAGS="-march=i686 -pipe -O2"....

List all your FAIL lines too... Maybe we can pin point what's happening.

I agree. Typically do '-march=ix86' (whatever x is), and if you want you can then do '-mtune=your_processor'.

Here's a question - based on that 'libstdc++' would be 'library of standard C++' functions or whatever, since Linux is written in "C", would it be safe to say that libstdc++ would be the least important of gcc, g++, and the other gnu parts? And that I would necessarily desire a perfect score only if I were interested in programming in C++ ?

FWIW I am currently happily beyond the glibc/gcc/binutils section and all is now smoothly cruising along, however when I finish the build, I plan on running the entire script in one big chunk, to see that I haven't missed or omitted any little tweaks & fixes I made along the way and make sure it runs start to finish error free, and I will at that time try removing -mtune or changing it to i686 for glibc/gcc and see what happens.

Just downloading a few tarballs I don't have yet, and should be finished the entire build in a few hourd (not including a break to bake cookies later ) and will then glue all my script sections together and run it fresh, hopefully for a perfect, non-stop compile.

Last step I suppose (besides some documentation) will be to write a second chapter to the whole process which will build the packages needed to make my new system into "Slackware".. That ought to be a LARGE project!

Well, the Linux kernel is indeed written in C, so you don't need C++ to compile it. But, other parts, such as the GNU part of Linux, may be written in C++, in which case you will need libstdc++. It's your choice. I think, eventually, you will need to install it, but it is not as important as C.