The 'because you can' factor is one of the best things about Linux. So many people don't understand this point.

I was just messin' with ya.

Good luck on your mission.

I agree, jong357's recomendation looks easier to deal with. Thanks jong your jaguarlinux site is nice too!
Thing is at the moment, trying to find a concise how-to called "Creating a new up-to-date toolchain on a running i686-pc-linux-gnu machine" is proving difficult.
The LFS docs are indeed confusing, but very detailed. The DIY docs are much easier to read, but are NOT as detailed. I'd like a combination of the two.
Confusing details are:
1 - Which combo of releases of GCC, glibc and kernel are actually suitable as a stable, reliable toolchain? I mean, will my 2.6.21 kernel, GCC 4.1.2, and glibc ??.??.?? work fine? Which glibc??
2 - Build environment: Since I'd like to upgrade my running system ultimately with my newly made toolchain, and proceed from there, where do I build? I plan to use an empty 5Gb Ext2 partition mounted on /mount/storage to make my toolchain. Is this ok? Or do I really absolutely need to create a new user account and set up all these $ENV's and paths and stuff?

Anyhow, I have my kernel (2.6.21 which includes 'make headers_install' ability) and I have gcc 4.1.2 already. I've now downloaded binutils 2.17 too. Now I need a glibc...

If anyone has a link to a clear, concise, understandable tutorial on building a new toolchain, I'd be delighted to see it. I have about 15 tabs open right now, each about making a new toolchain with varying degrees of completeness and complexity :S and none of which give a list of which componenets are NOT suitable for a toolchain, and only the DIY page giving a total of like 5 combinations of binutils/gcc/glibc.

Thanks for the ongoing help guys -- I WILL figure this out.

wow jong357, what you've done on http://www.jaguarlinux.com/ is just amazing, and a long time goal for myself.
GrapefruiTgirl - I'm also gentooizing my slackware and it's a lot of fun. I also like compiling everything that appears on the -current changelog
Don't forget to post your comments when you're done please

GrapefruiTgirl, the answer to number 1 is not so easy. You have to choose an eact combination which works together -the best way is to use the versions chosen by others and are known to work. This means especially the glibc, gcc, binutils threesome.

As I mentined the basic order for building a new toolchain is to first compile the new libs, then the binutils, then the new compiler. The complex part is understanding that when you do this the first time they are still not 'right' because they were compiled using your old compiler or a staically-linked new one. They aren't really 'right' until the new libs have been compiled by the new compiler and binutils. This is why every strategy includes extra passes. In the end the new compiler should appear to have been compiled by its' own self, using binutils, libs and kernel headers which were also comopiled by itself.

If upgrading from glibc-2.4.1 to glibc-2.4.2, for instance, you won't have any problems doing it on a running system. But if you upgrade from glbc-2.4.x to glibc-2.5.x you may have problems with backward binary compatibility. This is why you have to have either statically-compiled binaries which don't depend on the old or new libs to run or go through several chroots and passes and PATH chnages, etc. This is beacuse you need a basic system running with a shell and sed and other tools in order to compile the basic libraries and binaries, including the new compiler, binutils and glibc.

The toolchain itself is just the binutils and compiler. But they depend on the new libs, which are compiled using the headers for the new kernel version. But you also need a shell and many other tools while bootstrapping a new system -usually static make and sed. Most of the other stuff like awk, etc can be covered by using busybox.

Most people place all these new tools in a directory like /static or /tools for convenience. The compiler and binutils should be compiled and installed in separate subdirectories of the directory. This is because you need to control which binaries are being used during bootstrapping. Having the binaries in separate paths makes this easy by manipulating the PATH during the process.

The other list I gave with libtermcap, bash, etc is the list of programs for the new system apart from the new toolchain and glibc. Obviously the first thing you need is a shell for the new system. But bash needs either libtermcap or ncurses for the terminfo libs. So, libtermcap should be compiled first so the new bash can link against that. bash is often more complicated and also requires more than one 'pass' if you use ncurses to supply terminfo, because ncurses requires gettext, which requires terminfo also. This is whay you see multi-passes for bash, ncurses and gettext in most methods, especially if no static tools are being used.
After that you'll need zlib and gzip, tar and the utils-linux collection, then bin and so on.

Good luck with your project, GrapefruiTgirl. Keep us all posted on your progress. I intend to do a LFS/Jaguar/DIY thingy eventually - not ready for it yet.

Slackers Of The World Unite! You have nothing to lose but your minds!

Thank you guys so much for all the feedback and I will for sure be keeping this thread alive with updates (perhaps to the detriment of your sanity as well as my own ) and gnashley - thanks again for the continued support.

As of this moment (since actually having gone to bed sometime this morning) I currently have (as mentioned above) a new user account (build) with his home as /hda9/build and have been trying to follow the DIY instructions. I have:
GCC 4.1.2
Bash 3.2.017
Glibc 2.4
binutils 2.17
Autoconf 2.60
Automake 1.9.6

Now, for the most part, the instructions for creating the build environment seem to have worked. But first, here's one point (taking into account gnashleys 'order of operations'):
: DIY says start with BASH pass 1, MAKE pass 1, SED p1, BINUTILS p1, GCC p1 ... ...
: LFS says start with BINUTILS, GCC, Libc-headers (???), Glibc, ... ...

..so clearly quite different order of operations.. I have been trying to build BASH according to DIY instructions anyways, but './configure' is quitting on 'configure: error: C preprocessor "/lib/cpp" fails sanity check' and I've tried adjusting the environment to no avail, and so far no luck.

Still working on this; suggestions/ideas much appreciated..

SOLVED!

It seems I borked up my host-system's GCC and related tools
I just reinstalled the Slack GCC stuff from the DVD and all is now working fine..
Just did Bash stage 1. Make is next.. Update later!

I think it might be easier to do it the Gentoo way. I mean, build a whole new system in a different place, then chroot into there when you're done. That way, you don't actually have to update things, or maintain a working toolchain while doing so. I dunno, just thinking it might be easier. (It's probably even easier to install Gentoo, then modify it to be more like Slackware ...)

Well, it's going well now, I'm onto gcc now..
I borked stuff the other day while doing other stuff, so it wasnt related to what I am currently doing.
Right now, I'm working as user 'build' on a separate partition, and as I said, so far so good

No Gentoo I'm an updating, multiple-toolchain kinda gal -- I WILL prevail!

LOL

Read the "Rationale Notes" for bash, make and sed. It's explained why they are built in the beginning. And the order is near identical to LFS. Where it matters anyway. I also prefer to use the headers from the kernel. The libc project is long dead and the last 2.6.12 libc release needs patched to hell and back. But you can use them if you want.

Also make sure you read http://www.diy-linux.org/reference-b...roduction.html

That page answers alot (if not all) of your questions so far, with regards to what versions go well together ect...

DIY isn't geared towards 'teaching' like LFS is, atleast not with explaining every single little thing. LFS does however make it a point to gently walk the user thru what's going on. That's probably the main goal of LFS.. The author of DIY isn't really interested in such things. Which he also says numerous times in the preamble. If you find yourself having a difficult time, I'd suggest you try your hand at LFS a few times. Once you do LFS a couple times, their's not too much more you can pick up from them IMO...

OK.. Hiya jong357!
RE: your above post -- I've been reading ALL of the 'rationale notes' throughout this process, and for the most part understand what I need to. On a lot of points, the LFS docs are nearly identical to the DIY process. I've read both introduction sections as well.

Currently, all has gone extremely well I am happy to say, including the first round of installing glibc 2.4. I'm using the headers from my 2.6.21 kernel.

Anyhow, I am currently slightly stymied. I am at DIY section 4: The Chroot Phase.
To be exact:
4.1 - $PM_DEST - I'm not sure what if anything I should be using for this. In keeping with Slackware's system, the packages are typically kept in /var/cache/packages while the installation records are in /var/log/packages. Should I be using either of these?
This leads into the next question(s):

4.2 - Enter Chroot Environment - no problem. Done!
4.3 - Create Directories - Done!
4.4 - Perform Mounts - Done!
4.5 Create symlinks - Done!
4.6 - Create MISC files - Done!
4.7 - Create users - Done!
4.8 - Makedev-1.7 - Done!

4.9 - Manpages-2.50 -- Here the minor confusion starts: referring above to my 4.1 bit about the location where I should be storing the packages/tarballs which I will from here on be installing in the CHROOT environment, where should I be putting/extracting/installing the upcoming stuff from? Both DIY and LFS do not tell me where I should be sitting when doing this.
For example, for the "Manpages-2.50", would I just plunk the arckive down in / and work on it from there? Or should I put the archive in /var/cache/packages and install it from there?

-- Slightly confused, but still reading. Thanks for any further input if nothing else, I am learning stuff and having fun.

Hmm.. I may have just figured it out

I figure, as I am building the system in place, as if it were the real running system, I will just install without the $PM_DEST destination directory variable set (or rather not use it at all) because none of this stuff was ever listed in Slack pkgtools anyways. As this is all the 'base system' stuff, it doesn't really need to be listed in pkgtool either way.

OH, and, where am I putting the prchives? in /var/cache/packages and extracting them in there, and installing them. Then deleting the build directories.

OK, ongoing! Back in a bit.

When you've finished successfully - as I'm sure you will - you can write a book about it, and send me an autographed copy.

Nice idea BrianL..

Well, my latest glibc-2.4 "make -k check || :" finished with a "[make] *** error 2" with a few more messages around it -- none serious, and from what I gather, this happens quite often. Subsequent re-makes often finish sucessfully, but to be sure, I've gone back a step and cleaned out glibc and the build folder and am making it again right now.

Other cases I have read about which end with this error are caused my a forgotten symlink, needed for the test-suites.

Running make now. Update later.

PS - Am I imagining it, or is my newly compiled compiler compiling faster than it used to?! LOL say that 3 times fast!

O.k... DIY revolves around making binary packages whereas LFS does not. The $PM_DEST variable is the same as $PKG in a slackbuild script. So....

make install $PM_DEST=/tmp/package-man-pages
cd /tmp/package-man-pages
makepkg -l y -c n /tmp/man-pages-2.50-noarch-1.tgz
installpkg /tmp/man-pages-2.50-noarch-1.tgz

Then move on to the headers.

Once you start the chroot phase, you are building for your new system. If you don't make packages then your doing LFS really. Everything listed in the chroot section IS CONTAINED in slackware's pkgtools.... Those are the 'base' packages... So use the $PM_DEST variable, otherwise what are you going to upgrade your system with?

As for the glibc make check errors. I can't give any advice unless I know what they are. Don't take them so lightly like you seem to be doing. glibc is THE MOST important piece of software on any system. Get a bad build and your system is worthless.

Sure it is... Those most defenately are listed in pkgtools.

Sure it does... You'll never be able to upgrade or remove those packages ever if they are not listed in pkgtool.

It's told where to put your source tarballs and extracted source tarballs.
If you followed those directions, you should have a /mount/storage/temptools/src/tarballs directory. You put the source in there. You also extract in that same directory, build in that same directory and then remove the extracted source code after your done with it.

Any patches used in DIY are meant to be stored here: /mount/storage/temptools/src/patches

Go back and slowly read thru everything. Seems like your jumping right in with out a clear sense of the setup proceedure and goals of DIY... Look at your ~/.bashrc for the new build user. The SYSROOT variable should be set to /mnt/storage, the time zone variable should NOT be Australia/Sydney unless you happen to live near Sydney... I have a feeling you might have not personalized that stuff...

I guess I'm also unsure of what your really trying to accomplish. Are you just building a new system from scratch (LFS/DIY) and going to use that instead of Slackware (or dual boot), or are you trying to make binary packages with your new toolchain so you can 'upgradepkg' on your actuall Slackware system.

Either way, you need to install pkgtools on /mnt/storage BEFORE the first man-pages package. And, you need to be using your new pkgtools to make packages...

Here are my notes for accomplishing that:

http://jaguarlinux.com/pub/DIY/source/base-order.txt
Those note are 'jaguar' specific but you should be able to tell what's relevant. Starting at the "Toolchain:" part, you should read. You'll need to install SLACKWARES pkgtools along with tar-1.13. When your in the chroot stage, you should really be running the .SlackBuild scripts and not doing it by hand. Otherwise, again, your building DIY and not Slackware... If you use my scripts from my pub/ directory, then you'll be running 'jaguar' and not Slackware...

Another thing to consider is, The next Slackware will be running glibc-2.5 and gcc-4.2.0... Again, I'm not sure what your end goal is. I happen to prefer a 2.4/4.1.2 combo because it's really stable but if your going to be using these packages to upgrade Slackware, then you'll actually be downgrading slackware.

I'd stop where you are and look ahead and determine a game plan instead of blindly pushing thru with the refrence build at DIY.