Building firefox/mozilla/etc from source



Welcome, Guest \| Home \| Search \| Login \| Register


Author	Building firefox/mozilla/etc from source (Read 94559 times)
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #30 on: July 05, 2024, 21:50 @Jatoba, that is an excellent idea, especially now knowing having dual cpu's won't buy me much (anything?) in MacOS 9...a Mini with 1.4ghz would run rings around both the G4 tower, and, especially the 7600. I actually have one that is my "Mac Server" that has been running 24/7 for years (baring power outages!). The only hitch being having to rely on the hack to run MacOS 9. I wanted to keep to stock hardware/os as much as possible, and minimize "fun extensions", so when the inevitable crashes occur, I could blame the compiler/etc, and not something funky hardware/driver-wse. Of course, so much for being pure, as my G4 is using a non-standard cpu card (from a slower/older model, as I don't have the original), and the 7600 has a G3 card in it. I've been meaning to look into getting MacOS 9 to run on the mini, but have yet to try it... ---- So I've followed the setup instructions from the Floodgap page, but run into a Perl error when running the build script the first time. The error mentions AppleScript and says only a certain version is supported. My Perl is pretty good, so I'm going to look at the script itself, and the modules it loads and see if I can figure out what is going on. The error seems to involve the AppleScript support lib that is installed in the site_perl folder. I followed the instructions and dropped the tgz on the install script that was included with the CPAN archive, and can see it DID install something in site_perl. This was using SheepShaver, but I've copied everything over to the G4 and the 7600, and will try there later today...and will also go over the setup instructions again on those machines. It takes just over an hour to copy "everything" via an external USB drive: The CodeWarrior folder (with the ToolServer plugin and the various SDK's needed installed), MacPerl (with cpan and the required modules in site_perl), the entire Preferences from the System Folder (to get CodeWarrior, ToolServer and MacPerl, etc, settings), and, of course, mozsrc (after running the alias generation script).
Last Edit: July 05, 2024, 21:52 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #31 on: July 06, 2024, 06:01 Progress! It completes the "manifest" stage and, gets at least a ways through the "build xpidl" stage, before erroring out. But I've screwed around with the files/folders PLENTY, and wouldn't be surprised at all that I've messed things up somewhere along the way. I'm going to trash what I have and start over...and avoid a few goofy mistakes the next time around... ...Or maybe what I'm seeing is totally normal!: "The very first time you try to do a build, it will die after this point because CodeWarrior won't register the tool without a restart.". Maybe I'll have a very pleasant surprise when I boot up and work on it tomorrow! (Cross fingers). ---- On the 7600 CodeWarrior now won't launch, but crashes to MacsBug with a CFM error that sometimes mentions CoreFoundation (hence Carbon)...even the installer crashes so I can't reinstall! I think either mixing System versions and/or trying to copy Preferences from one system to the other to try and keep them in sync broke something. So, wipe, start over! I don't think I'm actually saving any time trying to copy things from machine to machine, which takes an hour anyway! Instead, each build should be set up separately by hand. Meanwhile, SheepShaver and the G4 are still happy... ---- These are just a few comments/gotchas I ran into while following this: https://www.floodgap.com/software/classilla/build.html On the line "Next, install the following modules.", it tells you to use the "installme.plx droplet", but I was confused and used "INSTALL.plx" instead! So none of the required Perl modules (other than CPAN over and over and over) were getting installed. I didn't think to look in the "droplets" folder...doh! The original author is NOT kidding when they say "Set the memory partition for MacPerl to at least 18MB". Even that wasn't enough, even just for the "installme.plx" steps mentioned above...I set it to 32m required, 96m preferred...otherwise it untar'd the tgz files, but then gave "out of memory" messages, and never actually installed anything. If it untars them like that (ie the script fails), trying to run installme.plx a second time (after increasing memory alloc'd to MacPerl for example) won't work, you need to trash the unpacked folders, or it will refuse to do anything. Also, for each module it will ask to convert file format/types, you need to allow it to do so. One of the required SDK's, which you need to copy to your "MacOS Support" folder is for Internet Config. I was unable to get the .sit downloaded from FloodGap's gopher server to unstuff (Expander doesn't seem to even try)...so I ended up using the one I already had for Goliath and Jabbernaut. They look like the same version so shouldn't be a problem... In the process of switching between MacOS X and MacOS 9 (and I unstuffed a lot of things on X I think), there were empty(?) ".finf" folders created EVERYWHERE. Part of the build process generates aliases, and I could see it looking at the .finf's. To avoid this being a potential problem (Creating extra aliases? Thinking they are part of the source and scripts trying to config them? etc etc) I'm going to unstuff everything again. On the other hand, they haven't seemed to cause too much trouble so far... CodeWarrior MPW, and the CW Plugin SDK are on the Reference (not Install) CD, and not part of a normal CodeWarrior install. In fact, I can't see where installing MPW is an option in either disk's installers, so just dragged it over. I know this worked because ToolServer via the menu works fine. One typo(?) in the instructions mentions a tool called "MakeStubs", I think they meant just "MakeStub". ---- FYI in case you've never used MPW, you need to press Command-Enter after commands to execute them in the CodeWarrior ToolServer window (or the MPW Shell). So, to test your setup (of at least that part) is good, type "MakePef" or "MakeStub" and Command-Enter and you should see the list of options for each command, etc.
Last Edit: July 06, 2024, 06:46 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #32 on: July 06, 2024, 20:15 Sure enough! The error I got was perfectly normal. Very glad I decided to try again before emptying the trash!!! ---- So now, on the G4 it is able to get through the "Compiles the IDLs and headers" step. For those following at home, the error you see says it is unable to create an alias to a particular ".xpt" file, the original is missing. Hunting down where it tries to create that original, and running the process in CodeWarrior by hand gives an error about the "xptlinker" not being found. This is exactly as described in the instructions. Restarting CodeWarrior causes it to find the plugin it'd generated! It also seems to complete the "Compiles the OS stub library phase...but gives an error in "Compiles the runtime...which...surprise surprise, is actually a problem building "NSStdLibStubs" caused by a failure linking "InterfacesStubs". It was easy to find by opening the .mcp files by hand, that you can see listed in the Perl output window. This turns out to be with my "ContextualMenu", supplied by theUniversal Headers...EXACTLY as described down in the "The runtime will not build (compiler or linker errors)" section of the instructions. The step where you use the newer headers, downloaded from FloodGap's Gopher server, aren't TERRIBLY clear, and I just (knowing it was very naive) dumped both the 3.3.2 and 3.4.1 ones into my "MacOS Support" folder. I knew it, probably, wouldn't even find them, and instead use the ones CW 7 comes with, which the Perl output window kindly notifies me are 3.3.0... Obviously, in hindsight, the instructions imply you are supposed to REPLACE the 3.3.0 ones, with the 3.4.1 ones... So I'll do that...and it might then be able to link in the "ContextualMenu" from those (using 3.4.1, but may need just "ContextualMenu" from 3.3.2, if I still run into a link error, as described)...BUT, what I've got built up to that point was with 3.3.0, so all that should be started over...I think trashing "Mozilla opt progress" file will do that... ---- Meanwhile, on SheepShaver, I didn't run into any "Out of Memory" errors installing the perl modules, using "installme.plx"...my MacPerl is set to 18m required, 32m preferred. Strange... I was able to get it up to the same point as on the G4, with the "InterfacesStubs" failing on "ContextualMenu". My CodeWarrior is the same as on the G4, so this is hardly surprising! I want to say the G4 (even at 400mhz) is faster than SheepShaver, but I don't think that is actually true...SheepShaver just FEELS sluggish, all the time, comparatively, but the build process seems about the same, or, maybe, a little faster. This is on a very low end Intel MacBook Pro, I think maybe the lowest you could get.... So I wasn't expecting a speed demon! Setting it up on my much higher end Windows desktop certainly wouldn't hurt... ---- Back on the 7600, I'll do a fresh install of MacOS 9...but what version? 9.0.4 like SheepShaver, or 9.1 which I'd been using...I think maybe 9.2.1, which I've got on the G4 won't run on it...at least it can't boot off the original Apple CD I used. It likely doesn't matter... Because, even if it takes hours, how cool would it be using such an old piece of hardware to build Classilla?!? ---- So on to tackling my Universal Headers...
Last Edit: July 06, 2024, 20:33 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #33 on: July 09, 2024, 10:58 @lauland About the mini G4 + Mac OS 9.2.2 combo and their "authenticity" when combined, I can reassure you of a few things: All the Mac OS files are actually 100% untouched and stock. The one file that did get tinkered with to make the combo possible, however, is the "Mac OS ROM" file. I think we can say that messing with the ROM file is, in a way, messing with the OS itself, since it contains much of, or all of, the Toolbox API itself. However, as far as I know from the (enormous) original thread, none of the Toolbox API nor anything System-related was touched: AFAIK, it's 100% purely hardware-recognition tweaks (trampoline boot logic? Boot scripts? Forth scripts?). This is the reason that the main thing not working with this effort is having volume control over the built-in speaker, and plugging in a tiny USB audio adapter is required. Similarly, I think sound input (microphone), and software that make use of such (as few as they are), can cause the system to crash. (Some people also seem to make it work by just plugging in a speaker or headphone that has its own built-in volume control, without any USB adapter, so that you can "bump it up" in order for it not to be near-muted.) Other than that, just about everything else is fine, if your mini is either the 1.25GHz and 1.42GHz model, that is. Well, there's still just one more thing, which is that, when you boot, there's a ~15% chance the mouse cursor can click, but not move, case in which you reboot immediately (e.g. via a "Restart" script bound to an F-key like F11), and once it boots successfully, there's never a concern of the mouse cursor getting stuck again, until there's another reboot. 100% everything else is pure original Mac OS goodness (other than the "glowy" Happy Mac icon they replaced in the ROM file, to indicate the tinkering). I had MDDs running side-by-side with 3 of the 4 mini models, all running the same software, from games to "productivity", to confirm the "authenticity". It all checks out 100% of the cases behavior-wise that I could see over all these years, whenever I compare app behavior also with other people running the same app on their "normal" Macs. The 1.33GHz and 1.5GHz, however, have a few extra "gotchas" with regards to some NVRAM settings set via Mac OS (e.g. some don't persist), so for example I can't tell it to always mount a RAM disk at start with Apple's built-in solution, although putting Make RAM Disk in the Startup Folder works (and allows for RAM disks bigger than 512 MB, as well). Can't rely on "Startup Disk" to change the partition to boot from (gotta set it from OpenFirmware if I want that), either. Some monitors are also less willing to cooperate with those two particular mini models, although that's not related to NVRAM, AFAIK. And that's about it. Personally, I think you can run Mac OS 9.2.2 on your Mac mini G4 with confidence if at one point you want to try it (we have "pre-built CDs", one which we call "v8" and another we call "v9"), but you make a fair point when you bring up the ability of being able to compile Classilla in a coffee shop! Can't really say we can comfortably do that with a Mac mini.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #34 on: July 09, 2024, 17:20 Excellent points (as always!) @Jatoba, you've got me itching to try! It would REALLY rock to get MacOS 9 on a mini, because they're just really solid machines (in my experience, at least). I'm not concerned at all about running "unofficial" software, other than the gotchas. Sound problems are very annoying, but if there's a workaround, a non-issue. It's how solid (ie not crashy) it would be...and, in this case, probably, from what I hear, very solid...as it seems like it's something Apple could have perfectly well done...if they'd wanted to. There's no technical reason some machines with G4's can't natively run MacOS 9...they chipsets, the hardware, everything needed is there (and extremely similar to machines that can). Apple just didn't want to support it. Oh well...since the compile time is very very long, I'm realistic, and speed isn't that big of an issue. I start it and then walk away and check back. Whether it could take less time is nice, but not actually a pain point...and, like I said, enough mucking with hardware...I've got to get the thing to finish building... ---- I've made a LOT of progress, and am up to the point where it tries to build a jar file for the java plugin, and SheepShaver either quits or freezes. I've tracked it down to a MRJ problem...it isn't the Classilla build process, Perl, CodeWarrior, MPW, at all. Doing a fresh install of MRJ, trying to run ANYTHING in the Applet Runner fails. (Completely outside CodeWarrior). I copied my SheepShaver drives over to my desktop PC (very fast!), and it does the same thing as my MacBook Pro...so it's either SheepShaver itself, or my System Folder has a problem. The next (obvious) step is a clean install of MacOS 9, with nothing Classilla related at all, and getting MRJ to work. Anybody else have trouble with MRJ on SheepShaver? ---- Now, you may wonder...what does it do on my G4 and 7600? Short answer, they don't get that far! This is when building it on multiple machines has REALLY saved my bacon, at least twice. Right now, they have build errors MUCH earlier in the process, in the "necko" component. If I didn't see SheepShaver sailing past that point, I'd be stuck thinking it was something I need to fix...and be wasting a lot of time. This has happened more than once, in fact, with another case where CodeWarrior told tell me (in a different component) it couldn't find a particular include file and it's RIGHT there (and in the access path) on one machine, but with another having no problem at that point. Very strange, but not completely unexpected, as building Classilla is very intense, opening (and closing) hundreds of CodeWarrior projects, etc... What I then do is toss the whole build environment that has the weird errors, and copy the whole thing from the other machine that gets past that point! Did the files get corrupted? Lose their file type? Is CodeWarrior messed up? Just confused about file paths? Who knows. It's not worth the time to debug, since it gets past it no problem at all on the other machine... ---- So that's my next step, copying the whole thing (MacPerl w/modules, mozsrc, CodeWarrior) from SheepShaver over to the G4 and 7600. I'm just relieved the SheepShaver problem doesn't seem to be with the build process itself! So, at least there, I haven't done anything PARTICULARLY stupid... If it still doesn't work, then I AM doing something goofy somewhere in the process of copying the files from machine to machine... Which will be very good to know!
Last Edit: July 09, 2024, 17:25 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #35 on: July 11, 2024, 17:04 Whoohoo! Finally got Classilla built, and am typing this from it. A bit of a pain, as expected, but got over the humps, and hopefully can save others from getting stuck in the same places... The problem with it sometimes not finding incude files, etc, for no reason, on one machine and not the other ended up being due to broken aliases. Trashing the mozsrc folder and unstuffing a fresh one (and remembering to run the ClassillaFixAliases.pl script!) fixed the issues. I'm sure those aliases got broken while copying the build folders from machine to machine... FireFox/Mozilla uses a "dist" folder for the end product(s), with aliases/links to the actual files, etc etc. (So it was including those, and not the files in their original locations.) On my G4, it still won't get past the MRJ Plugin step, but instead of crashing like SheepShaver, it just reports it is unable to start the Java VM. I didn't bother installing MRJ, so that's probably all. Meanwhile, using qemu and a fresh install of MacOS 9.1 I was able to build the plugins fine... (The 7600 is still building afresh, as we speak...) It looks like there are corrupted resource files in the "wizard" part of "xpinstall". The files don't have resource forks, and opening them in BBEdit seems to show what looks like raw resources (in the data fork). I checked freshly unstuffed mozsrc's for 9.3.3 and 9.3.4 and the files are just like that, so it's nothing I did. Opening them in ResEdit helpfully adds empty resource forks and allows the compile to complete...but CodeWarrior refused to link otherwise. So that particular installer/wizard thing may be broken...maybe nobody actually uses it? ---- So I'll type up my notes, with screenshots, for where I got stuck and/or didn't understand the instructions (or they could've been clearer...or didn't mention something), etc. I'm not sure if there are actual files that would be really useful for sharing...I could put my SheepShaver/qemu disk images someplace for whomever would like them (though they total ~5g for the final build version with the System, CodeWarrior, etc etc, everything). Otherwise, maybe just the MacPerl and "MacOS Support" folders ready-to-go. But then you still need to set a few particular Preferences for Perl and CodeWarrior...or you'll get nowhere fast. So the question is what (other than my notes) would be useful for folk out there? If you want to fix or modify it, starting with it fully built would be the way to go. And/or you could START with that, clean all the built binaries bits/parts, and be able to re-build it yourself...knowing that it'd (probably) work. Which is nice to be able to say you did it...but not terribly useful otherwise! I'm guessing there are three kinds of people interested in Classilla: 1. Those that just want to run it. They don't have a need to build it. 2. Those that want to hack on it. They definitely need to build it! 3. Those that want to say they've built it, or just build it "because they can". I guess I fall into that category right now. Anyway, I'm open to "next steps" or "suggestions"...
Last Edit: July 11, 2024, 18:03 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #36 on: July 12, 2024, 20:20 @lauland That's awesome!!! I can't wait to try it myself! It's especially encouraging that you took notes and plan to share them, thus "paving the road", so to speak, for everyone else! Quote from: lauland So the question is what (other than my notes) would be useful for folk out there? I think the notes would be golden. Screenshots are a (huge) plus, but I find the notes themselves the most valuable. I can very-well imagine just how you must have stumbled upon all kinds of pitfalls that were either undocumented or not-so-clearly documented, or even just not easy to deal with for people who lack the required knowhow. So the fact you reached the end goal means your notes would be instantly incredibly helpful. I think to "get the feet wet", if you feel inclined, you could make a Garden page for this, like "(Unofficial) Build Setup for Classilla", or just "Platinum Surfer" (or whatever other name you want), then upload the "readied" MacPerl and "MacOS Support" folders, with instructions for whatever people going into that route need to know to "complete the setup" for building. If, after you did all that, you still feel inclined to further facilitate things for people to build the browser, then your idea of uploading the 5 GB "bundle of everything" (from OS to CodeWarrior, the source code and various precompiled files) can be done. I know I would download it and run it! Again, don't worry about the bandwidth, but do be prepared that uploading a 5 GB file in the Garden can take many hours, and there's a non-0% chance the upload will fail and the file won't actually attach to the page (but it probably will succeed, I think: I have done so myself quite a number of times).
Last Edit: July 12, 2024, 20:24 by Jatoba
wove 1024 MB Posts: 1363	Reply #37 on: July 13, 2024, 22:20 A bit off topic for building FireFox but @lauland mentioned OS 9 with qemu and I was wondering if perhaps you could share your QEMU configuration file and a bit of information about the system you are running QEMU on.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #38 on: July 14, 2024, 21:33 The MRJ problems were quite strange. I can understand SheepShaver, but the G4 and 7600 would still give "Reinstall" and "Check if installed correctly" errors. Attempts at just reinstalling various versions of MRJ had no effect. So I did fresh clean system installs, 9.1 on the 7600, and 9.2.1 on the G4 and was able to get past that point, finally. (The G4 doesn't like my burned 9.1 cd, and the 7600 can't run 9.2.1). On both of them I trashed my "mozsrc" folder and did a fresh unstuff of it. Both now build...I did a completely clean build on the 7600 which took just under 4 hours...but the resulting app gives a type 2 error! The G4 build was interrupted, so I don't have a total build time, but will get one later today...I'm guessing...2 hours maybe?!? ---- Now, I definitely may have made some mistakes or poorly thought out choices, but I don't think any truly stupid mistakes along the way. So I'm extremely glad I was attempting the build on multiple machines. If the qemu build didn't end up working perfectly, I still might think there were issues with the build process itself. But I know it MUST be something I did. The qemu build was 100% from scratch, as I couldn't get it to read the sheepshaver disks easily, nor did it supply an easy was to copy files from the host (ala SheepShaver and Basilisk's "Unix" hard drive). I know it's possible, but I'm glad I ended up not doing it, as the completely clean attempt was the only one that worked! Here's where I am right now: SheepShaver on Intel MacBook Pro: MRJ crashes. SheepShaver on Windows PC: MRJ crashes. PowerMac 7600: Builds but crashes with Type 2. G4 tower: Builds but crashes with Type 2. qemu on Apple Silion MacBook Pro: Builds and runs successfully. So the obvious next things to try on the G4 and 7600 are to reproduce what I did on qemu: Start over, download and install EVERYTHING from scratch. For SheepShaver I'll see if clean OS installs will get MRJ to run. The System Folders I'd been using on all of them had been there for a while, same ones I used building Goliath, Jabbernaut, and several other projects, so I didn't suspect anything weird with extensions, etc, but there must've been SOMETHING...right? ---- @wove, absolutely will share my qemu experience. I saw your post the other day and thought "Dang, EXACTLY the same time I was trying it out...great minds think alike!". I'd heard qemu could run MacOS 9 and some people reported good experience, maybe better than SheepShaver, but had avoided it simply due to the fact that it was all command line (officially, and didn't want to fart around with the various 3rd party gui's)...I may be smart, but I'm also lazy. So I wouldn't even have tried it except I had trouble finding an Apple Silicon version of SheepShaver. (I've been told they are out there...but I had trouble when I looked...and am VERY glad I didn't find them...). Installed qemu via macports, and was very pleasantly surprised that, other than all command line, it was relatively quite simple to setup and use. I don't have a "config file", but this is the command line I use to run it: qemu-system-ppc -M mac99 -m 512 -hda macos9.img -hdb extra.img -netdev user,id=mynet -device sungem,netdev=mynet -device usb-mouse -device usb-kbd (I read using the usb mouse/kbd helps with input smoothness...) macos9.img is 2g, and extra.img is 8g, both qcow, created with qemu-img. I used two drives just in an attempt to keep the OS and the build environment separate, although I now think that is not only not necessary, but probably confusing and maybe an all around Bad Idea(TM). I downloaded and installed MacOS 9.0.4 from MG (via the host of course), since it was the same OS version I've been using with SheepShaver. Then, inside the running qemu, I downloaded CodeWarrior, the pre-built Classilla binary, and 9.3.4 source from MG using the Internet Explorer that came with the freshly installed MacOS 9. I used the pre-built Classilla itself to download the various needed other parts (Perl, perl modules, etc etc) from the Floodgap gopher server. So it was completely clean and from scratch...and very likely why it was the only build that produced a working binary!!! ---- I'm not going to upload anything anywhere until I'm sure it won't include something goofy I'm did...so right now, only the qemu build is known good. Until I know one of you guys could download things and get a build going, it'd be a bit of a waste of time... ...although you guys ACTUALLY trying what I have might help figure out what is going on. Just the MacPerl and MacOS Support folders get you quite a way. The steps would be: 1. Download and unstuff classilla source. 2. Download and install CodeWarrior 7. 3. Set up MacPerl with modules. 4. Set up MacOS Support additions/replacements for CodeWarrior. 5. Run fix aliases script. 6. Run build script. 7. Get coffee...go to the gym...walk the dog...take a short day trip...etc. So starting a MG page just with just the configured MacPerl and MacOS Support isn't bad idea. Along with the above steps. I absolutely don't want to cause any controversies or step on toes or otherwise ruffle feathers about the name and/or any purported/mistaken "support" for a build...but not including a binary sidesteps all that, really. It would probably be best to just start a discussion on MG about what to post/upload...obviously there will be a signal-to-noise-ratio expected, but there are folks much wiser than I, or, simply more invested in the politics, and will want (demand?) to give their 2 cents worth.
Last Edit: July 14, 2024, 21:52 by lauland
wove 1024 MB Posts: 1363	Reply #39 on: July 15, 2024, 04:12 @lauland, Thanks for the command line startup for MacOS 9 on qemu. And more thanks for jarring the cobwebs in my head. I have been using the UTM wrapper of qemu and for unknown reasons I just never occurred to me to use MacPorts to just install qemu. And then discovering I can also install VirtManager. Yeah, I am lazy and loath to have to learn anything new MacPorts has been building qemu for several hours now on my 2009 17" MBP with a C2D processor, so I am probably a good solid day from knowing how this will turn out. Hopefully though I will be able to move my VM collection and new VMs from system to system, with ease.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #40 on: July 15, 2024, 18:53 @wove I'm running it on a "brand new" apple silicon machine, so macports included a binary (didn't have to build it). On my 2016 Intel MacBook running Mojave (so I can keep running 32 bit binaries) it's a different story...the build of qemu fails with the typical obscure macports kind of issues. A real pain to figure out slash debug slash fix, if it is even possible without hacking macports...which is no fun. (And obviously, there's no support on such an "old" machine). I'm thinking you (and I, on my Intel machine) will have more luck with prebuilt qemu binaries... ---- Did rebuild of 7600 using same "from scratch" steps as on qemu, but gave up because either its net connection (which should be good) is just too slow, or Internet Explorer is acting up. Using it to attempt downloads of Classilla pre-built binary, source, and CodeWarrior 7 disk images all say they finish, but only get a few megabytes in...giving up for now, and will just copy files over from G4 via usb drive... Rebuild of G4 mostly going well. Ran into error with MacHeaders I hadn't seen before when it got to the MRJ plugin part...hard to believe, but it looks like none of the source up to that step includes MacHeaders?!? Whenever you upgrade the actual CodeWarrior IDE application binary, you typically need to rebuild the MacHeaders...looks like I may have done the 7.0->7.1 update on the G4 (and thus needed a rebuild I didn't do), but not qemu, which is why it didn't happen there. Rebuilt MacHeaders and was able to get past that point. Cleaned build folder and started over, so I can give you guys a "total build time"...in a couple hours? Have tried multiple ways of getting 9.0.4 System Folder for SheepShaver...including downloading prebuilt ones MG has...and ALL of them hang when trying to launch MRJ. I've done a preliminary search for "sheepshaver mrj problems" (and similar) but haven't turned up anything obvious, but my conclusion is that, maybe, MRJ just doesn't work in SheepShaver...at least in 9.0.4. Since the qemu build went so smoothly, I'll probably just abandon SheepShaver for now and go with it.
Last Edit: July 15, 2024, 18:54 by lauland
wove 1024 MB Posts: 1363	Reply #41 on: July 16, 2024, 16:11 Thanks for the pointers @lauland. UTM upaded and then dropped the OS 9 image. My OS9 VM went all wonky. I tried installing qemu via MacPorts on El Capitan and had no luck getting it working. I then installed QEMU using HomeBrew on my 2019 MBP which installed without any problems. I used your command line start up, pointing to the OS 9 image I was using in UTM. It works and it works well. I have OS 9 running in QEMU very well and am very happy with the results. Thanks again.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #42 on: July 16, 2024, 17:16 @wove Very cool! I'm pretty happy with it...it even seems more stable than SheepShaver...and I'm surprised how fast and responsive it is. Although I haven't compared "apples to oranges" by running qemu vs SS on the same machine...so some of the speed has to just be my Apple Silicon machine... I'd suggest anyone else out there give it a try! (And don't be put off by the command line). And note that since qemu is a hardware level emulator, it includes an MMU, which SS doesn't, so you can run beyond 9.0.4 and use virtual memory! I was also unable to get a macports version of it on anything but my Apple Silicon machine...so installing it via homebrew for others is very smart! ---- Finally got running binaries on both the 7600 (just under 4 hours to build) and the G4 (just under 3 hours)! The total disk size for everything, including MacOS 9, CodeWarrior, the source, and the build results is a bit over 2.5g (The larger sizes I'd quoted before were for my qemu/SS disk images). I may look into a way of disabling the part of the build process that requires MRJ so I can get it building on SS. The source archive actually includes pre-built plugins already, so skipping rebuilding them shouldn't be harmful. (Although mucking with the build process may very well be harmful to one's sanity!) ---- I've figured out transferring a partial (or even full) built mozsrc folder from machine to machine is a BAD idea. I'm now about 85% convinced that either ClassillaFixAliases.pl and/or ClassillaMakeClean.pl are NOT working fully. Something is left behind that is changed during the build process, which then cause problems with missing include files...I haven't checked, but am guessing stale aliases. You MUST use a fresh unstuff of the sources. But, for me at least (and I may STILL be doing something not quite right, but I'm seriously doubting it at this point), there are two issues in the 9.3.4 source archive: There are two files that should have resource forks that don't (in xpinstall/wizard/mac/rsrc), and the dist/viewer/Plug-ins folder has already built plugins in it (which the build process will refuse to overwrite and halt). These both need to be fixed, so a new version may need to be uploaded to MG (and anywhere else). ---- So now I'm thinking I'll just start adding to slash updating the main MG Classilla page with my findings and useful bits and hints for building it. No need for a separate new page (and/or discussion), and if I don't include any built binaries, it doesn't even need a new name that way! So, no need for something like an "Unofficial Classilla Development Toolkit". On reflection about it, the whole idea behind the original author's "if you release a new version, please give it a new name" is all about (implied) end user support with the binary. As in he does NOT need to be bothered by people saying "I downloaded Classilla from MG (or anywhere) and such and such doesn't work!!! Your app stinks! You need to help me!!!" I don't want to be bothered by that either, and don't REALLY want to take on the mantle as the new "Classilla guy". I'll absolutely help ANYONE who would like to build it, and am definitely willing to help look at bugs, but the code base is very old and hacky, and "supporting" it would be a huge can of worms.
Last Edit: July 16, 2024, 17:32 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #43 on: July 17, 2024, 10:23 @lauland The Garden page looks great with your build tips, they are straight to the point and clear. They clearly cover issues people would stumble upon and waste hours on if it wasn't for your tips to rescue them from the pit. Thanks as always! I'm glad you got this far and covered all this ground for future maintainers-to-be. I also don't think I can be "The One Full Maintainer", but I wouldn't mind attempting to clean up some corners. In fact, for whatever work is put into the new codebase, I think we definitely would want to add nothing new for quite a while, and instead "clean the house". Improve/Simplify the build experience, fix up broken tools and other parts, like how you figured out the wizard part had two files with broken resources, and the importance for them to be fixed in order to build everything. "CleanZilla" first, "NewZilla" later.

Bolkonskij Administrator 1024 MB Posts: 2023	Reply #44 on: July 17, 2024, 15:43 Great efforts @lauland! I, too, would like to thank you for putting up the build info, this might save somebody with a serious interest many hours. That said, I like Jatoba's idea about slimming it down into a CleanZilla first. Maybe, if the codebase was more clean, somebody would feel like taking up the task? Maybe Cameron would feel motivated to contribute as well? ;-)

	Pages: 1 2 [3] 4 5

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.