I think I need to cut down on the caffeine.

Never! Great write up, lauland!

"Jabbernaut for m68k new attempts"
https://system7today.com/forums/index.php?topic=3802.msg16829;topicseen#msg16829

I plan to add notes about all the mistakes I made in the first attempt, and how I, in many cases very haphazardly, solved them...at some point...

----

The main key was the fact that CodeWarrior, like pretty much all Mac compilers, has a feature that compilers on pretty much every other platform don't have: Recursive include file directories.

Open any project in CodeWarrior and go to the project settings and then "Access Paths".  Look at the directories and for each line you'll see a checkmark, a little folder kinda icon, what it is relative to ("Project", "Compiler", etc) and finally the actual path.

I had absolutely no idea that the little folder kinda icon was a button!  And what it does is toggle if that particular directory is searched recursively or not.  I've used CodeWarrior since it came out and I never knew that.  I'd never ever clicked on it.  I thought it was just saying "This is a folder" or "This folder exists", etc.

----

This very rarely has any effect...in fact, it only does when you have two include files with the same name...in different directories...and one (or both) of them is (are) in subdirectories inside that folder.  If you're coding right, you have unique filenames for each include file whenever humanly possible.

...but...it can happen...and it does happen with GUSI.  (Grand Unified Socket Interface...I think).  It is a package of functions for Macs that implements something closely resembling the standard Berkley Unix socket api...and other functions that are needed to do this.  This was extremely useful for porting software for the Mac.

The thing that had me pulling my hair out, and barking up many wrong trees, were two (or more?) files named "time.h".  Most Mac C libraries do NOT include a "sys" folder with, among other things, "sys/time.h".  Look in the source of a lot of software that originated on *nix and you'll see #include <sys/time.h>

Many Mac compilers DO have a time.h, they just don't put it in a subdirectory called "sys".

I was getting very strange compiler errors revolving around GUSI's sys/time.h and CodeWarrior's time.h...in fact, sys/time.h INCLUDES time.h!  So...cutting to the chase, if you use GUSI in a CodeWarrior project and you have that little "recursive include file directory" icon turned on for the GUSI headers, just about no matter what you do, you end up with a circular reference. 

Most well written headers have something like #ifndef MYNAME_H" "#define MYNAME_H", then their actual content, and finally an "#endif".  By doing this, they ensure their content is only included once, regardless of how many times they are included.

So...with the "recursive include file directory" trick, if you have something like that, you'll see it saying it can't find definitions...if the header DOESN'T have the "#ifndef MYNAME_H", you instead get warnings/errors that things are being redefined.  Either way, if you don't know that somehow something like sys/foo.h, if it has #include <foo.h> in it, ends up including ITSELF, you will go crazy like I did.

----

The other key, and less irritating, is that CodeWarrior will ignore the path files had when you added them to a project the first time...and find them AGAIN, going just by the name (ignoring the path), every time you make changes to the "Access Paths".  So if you carefully dragged "time.h" from the GUSI folder to the project...then removed the GUSI folder from your "Access Paths" (or reordered things), the "time.h" you see in the project will be SOME OTHER file with that name...the first one CodeWarrior can find looking through all the directories...blah blah blah blah.  You can imagine how this bit me, before I saw it doing it, and my carefully constructed project file contents changing before my eyes...

With Jabbernaut, this was happening because the "Zoop" folder contained several different versions of the MacZoop framework.  They were all there because it wasn't clear which one was needed for which Jabbernaut project file.  So, when trying to build it, you could end up having a source file that is part of one version of Zoop including a Zoop header from a different version, etc etc.  Until I figured out that the only Jabbernaut build that actually worked used Zoop 2.5, and removed all the other versions and optional add ons from the "Zoop" folder, things were very confusing.

----

I will spare you how I FINALLY completely accidentally figured those out, because, as you can plainly see, I am EXTREMELY VERBOSE. 

I planned on posting the above explanation to system7today, but am trying to pace myself because I know, when I am in the right mood, I can end up completely dominating conversations, and driving everyone slightly(?) crazy.  And the last thing I want is to make system7today (or anywhere else) into a "laulandtoday" ego echo chamber.

I probably shouldn't speak unless spoken to...eh?

I'm going to shut up now!

I've got another upgraded Mac mini G4 w/ power adapter for auction. This one is a 1.25 Ghz machine with the following upgrades:
- 128 GB Toshiba SSD via ATA to mSATA adapter
- New OWC 1 GB stick of RAM
- New Clock Battery
- Pre-installed Mac OS 9.2.2 distribution from MacOS9Lives.com

See the description for detailed condition notes:
https://www.ebay.com/itm/126442275453

All topics have been moved but the German ones. I simply don't have the time right now. I will get around to do that as well soon

And as always; nothing has been deleted, only moved.

I managed to get my changes persisting, and narrowed down the `probe-all` issue to the Ethernet device failing to be opened in the `finish-device-tree` step. This happens on all of the G4 machines that I tested.

I've spent a lot of time on this today and unfortunately spoofing the older chipset didn't result in any success. I wasn't expecting this to work but it was worth a try.
Thanks so much for all the help joevt, I've learned a lot from this thread.