|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Building firefox/mozilla/etc from source (Read 94560 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
Reply #15 on: June 22, 2024, 06:41
Passing the "sysroot" flag to the compiler to make it use the 10.6 SDK on 10.7 didn't seem to help at all in building FireFox 8 on Intel, still the same errors about a bunch of NS_* not being defined. Either they aren't in the SDK (but where else would they be?!?), or it is ignoring the flag. I'm going to try copying the actual 10.6 SDK from a 10.6 machine (and put it in place of the 10.7 one) and try that. Funny how just going from 10.6 to 10.7 completely breaks the build. ---- I've given up trying to build several of the variants from my old snapshots because it occurred to me I'm doing so on CPUs that didn't exist at the time! Trying Arm (aka Apple Silicon) builds is especially futile, as there's no support at all for those processors in old source trees! I realized it's just as futile trying 64-bit Intel builds, if the source was originally 32-bits. I could get around this on older versions of MacOS X which still supported building 32-bit Intel binaries...this would normally be as easy as passing "-m32" to the compilers, but I'm not hopeful it'd honor it, and/or it might override it in the very complex Mozilla/FireFox Makefiles... ---- ArcticFox requires not only python 3.x, but an actual executable named "python3", which the version of MacPorts I've got on my 10.6/10.7 machines just don't have. I might just create a link to "python" and see if that works. The problem is it also has "ccache" listed in its requirements...but maybe it isn't a real requirement, and just to speed the build up? My 10.6/10.7 MacPorts seems to have it, but I can't install as the tarballs of the ancient version seem to have been removed from the official servers, I think. I might be able to build it (and a "python3") by hand. On the other hand, again, I might just be using too new of a branch from the repo. I need to find the branch that corresponds to the binary I "daily" use on my 10.4 iBook...still might have been cross-compiled on a newer MacOS X, but since that alone is such a pain, maybe not? Maybe I just need an older version? ---- "Classilla m68k": So I'm guessing the only sane way to take care of the 200+ .mcp project files would be an applescript (or perl) that'd open each in codewarrior, do an xml export, then sone other part of the script would kludge the xml to change the cpu type (and much more probably!) and then import that hacked xml, and save as a fresh .mcp...going over the entire tree, for every .mcp it could find. Yikes! And that'd have to be done before even a single file compile (and all the ensuing hacking) could be attempted! So, a REAL pain in the butt. The "mutant compiler" would basically be similar to what I used on Goliath, ie it'd be CW 7.1, but with the m68k compiler and linker plugins, but it'd need to have "MacOS Support" from 7.1, and who knows about "MSL"...maybe could use the 6.x binaries, but phew, like I said, even building this beast NORMALLY as is, is a major undertaking! Wait...no...I did the opposite...I used CW 6 with "MacOS Support" and "MSL" from 7...so I had CW 6 .mcp files. So, no, THAT wouldn't work because it'd entail using whatever dialect of C++ CW 6 had, while the author used 7.1, so, yet another huge block to deal with. (I wouldn't even hazard trying to build it with just 6, the language differences could be big). And, just for the record: "Removing" OT would mean WRITING new MacTCP code...and that...well...that is zero fun. I would not even begin to consider NOT using shared libs (ie CFM-68k) as the entire thing is made up of hundreds and hundreds of libraries, with the actual binary being quite small. Even trying to build it as CODE resources I think would be a mark of serious mental illness. Jabbernaut used MacOS 8.5+ Unicode system support, and I totally cheated/kludged it out for the m68k version. It seemed to work ok, and I think if it actually ran into Unicode it'd just display nonsense, but truth be told, I never tested the edge cases, barely tested at all...and never heard back from anyone trying to use it with foreign (diacritical) characters to see if that still worked. Doing this for FireFox would be about 10 times harder, as it has EXTENSIVE complex i10n support. Doesn't mean I won't at least make a try...or at least start one...if I ever even get as far as dealing with the .mcp files, that is! I seriously would not want to be the only one doing all the "lifting" ("heavy" and otherwise), but if I get it to the point where even a single file compiles, others would be more than welcome to pick it up. There might or might not be enough interest. As has very rightly been pointed out, where/how would you even run the thing? (I have visions of virtual memory killing disks from thrashing...and it taking 10 minutes just to start...and pages taking 5 minutes to load...watching each character slowly render...etc) Just for emulation is VERY niche. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: June 22, 2024, 07:13 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #16 on: June 22, 2024, 10:56
|
@lauland Because Classilla (and its predecessors) are just so monstrous compared to most other projects, perhaps we should not set our sights into the m68k stuff just yet. The official build instructions are quite challenging enough that I think we should first see if we can compile it 2 or 3 times... And I say "2 or 3", because it seems the compilation steps might include some quirks that can actually change the steps a little if it is, for example, the 2nd time we compile it rather than the first. So if we can compile it a 2nd time, then a 3rd time, then maybe a 4th time, then quite possibly we got "control of the ship". So I think, for now, I believe it is already ambitious enough, and our primary goal, that we: 1. Compile Classilla and confirm it's working (!); 2. (Stretch goal) Clean up some of the things? Like getting the debug build to work, and/or making the associated XML files be up to date etc.? (Are they XML files that correspond to the .mcp project files? Did I get that right?) 3. (Stretch goal) Remove easy-to-remove dependencies we might not actually need, if any? It's a bit of a shame to remove Unicode support, but we can consider. Maybe there could be a non-Unicode build for older Macs, even older PPC Macs on 8.1 and earlier, and a Unicode-supporting one for the Macs that simply can pull it off. Personally, I want to try at least compiling Classilla myself. Might be too much for n00b lil' me here, but I'm more than willing to try. It would be a project in and of itself.
Last Edit: June 22, 2024, 10:57 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #17 on: June 23, 2024, 02:23
|
You are a wise man @Jatoba! (As usual!) Ok, I'm thinking when it says build on MacOS 9, it REALLY means it. As in, not the Classic environment. Reading the instructions I don't see anything SPECIFICALLY that'd preclude it, but I had real troubles in another project with AppleScripts, which should've been fine in MacOS X, but were just a serious mess. (This was OpenSSL for Goliath, where it was meant to copy headers, change file type/creators and probably more, but I never got it to quite work, as I was using a mutant OpenSSL anyway, so I ended up doing the copying/typing by hand). That means a fast machine that can run MacOS 9 natively. The fastest I've got is a TiBook @ 667mhz, which is much slower/smaller than the original author's machine...the hard drive will be tight for FireFox/Mozilla builds. So when they say 80 minutes, I'd expect (maybe) four times longer! Let alone it can get VERY hot...I'm planning on letting it rest from time to time in the middle of build, so it doesn't commit self-immolation. I've got an expanded desktop dual G4 with a lot more ram, but it won't boot MacOS 9 natively, even though it would've originally came with it (see other post where I ask for help figuring out THAT mystery). This is very close to what the author used and I'd really really really prefer using it. ---- So, I'll start setting up the build environment on the TiBook and see how far I can get. It DOES sound pretty intimidating, dealing with the MacPerl and ToolServer magic, especially getting all the right versions of the required packages (both Perl and otherwise going in MacOS Support), etc. It sounds like it doesn't use the Makefiles at all, which, I guess, should really be a big "DOH!" from me...recreating the build process via Perl. Luckily I'm a bit of a Perl nerd, and can read and debug it (as much as is possible for Perl!!!)...but not much experience on MacOS Classic! The various steps are familiar, as I've seen them being done building FireFox in the standard and normal way (on Linux and MacOS X). It looks like the author has a bunch of the parts needed on their Gopher server (not otherwise avail via ftp/http anywhere?!?)...so I'll have to look there. Once I've assembled a build environment, I can stuffit it up and share to spare you guys the time and pain of setting it up...and it DOES sound a bit painful and time consuming, doesn't it? Will 100% respect all involved's wishes involving not distributing any binaries (when/if I have any!) without name change, but thinking they wouldn't mind just the build environment as much...but will give even that a goofy name too if that is required, of course.
Last Edit: June 23, 2024, 02:26 by lauland
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #18 on: June 23, 2024, 05:07
|
a step-by-step process, when the name and icon come into play, that will be at a much later point..gotcha! I thought it meant it would stay in place 
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #19 on: June 23, 2024, 08:25
|
Quote from: lauland ...and it DOES sound a bit painful and time consuming, doesn't it? More than a bit... I'm sure it would motivate some people into tinkering with Classilla if all the tools were gathered and made to be all in one place. That is not a bad idea at all. Quote from: lauland Will 100% respect all involved's wishes involving not distributing any binaries (when/if I have any!) without name change, but thinking they wouldn't mind just the build environment as much...but will give even that a goofy name too if that is required, of course. "Goofy name"... iZilla? Which comes in various different "flavors", like the original iMac? In which each flavor is a different build type (i.e. Unicode flavor, non-Unicode flavor, AltiVec G4 flavor, generic PPC flavor etc.). I see the name "iZilla" out there for a number of different things. Hopefully that won't be an issue? To differentiate it, it could present itself as iZilla, but in the formal jargon, be presented as "iZilla Web Browser". The name also sounds fitting for the era of the systems Classilla is built for, namely Mac OS 8.6 ~ 9.2.2 (and Classic-capable OS X). I don't like the "dead dinosaur" motif, though, nor calling the actual, natively-booted, original, real Mac OS as "Classic", suggesting it is obsolete or a has-been. If anything, it's much of the contrary: the modern stuff has become a beast of the unacceptable. Anyway, I'm probably overthinking this "iZilla" stuff, though, any goofy name will do. Discardable or permanent. "Potato Beef Browser", "Cookie Jar", "Web Swatter", "Webby", "Arachnid Unicorn", "Serial Webber", "MacWeb", "Make HTML Great Again", "ZapZilla"... Sorry, I will contain myself, and focus back on the build stuff. 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #20 on: June 23, 2024, 21:17
|
Well, a big hitch in that my TiBook's drive decided it was "a good day to die"...or at least become terminal. I made a backup of it last night because I had the Golaith/Jabbernaut dev setup and wanted to save it...but this morning, won't boot into MacOS X...command-V shows it "Checking disk" and then "I/O Error"s. It'll boot into MacOS 9, but Disk First Aid and Norton Disk Doctor give up. I'm thinking trying to build it on such a fragile (and precious!) laptop is a bad idea in the first place...so am going to look into doing it on the "Mystic" G4 desktop...if I can get it booting MacOS 9 natively...next best machine would be G3 and not enough ram...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #21 on: June 25, 2024, 19:12
|
I've been wanting to build the latest version of ThunderBird, FireFox's email client sister, but it required the 15.4 sdk, and my work laptop was only MacOS X 14.x...so I upgraded (including latest XCode)... After doing so, the FireFox build, which was fine in 14.x, failed with "unable to find suitable linker". Saw this was reported as a bug at mozilla hq. Turns out it was trying to invoke "lld" directly (and not just via clang or gcc, etc), which seems to no longer be in the path in MacOS X 15. I tried just copying it to /usr/local/bin, but ran into shared lib linking issues, so installed clang-15 via macports, which includes lld in /opt/local/bin...this worked perfectly! Was also then able to build ThunderBird, finally. Humorously, the FireFox builds call themselves "Nightly"...so ThunderBird calls itself "Daily"...hehe...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #22 on: June 27, 2024, 16:22
|
Another snapshot I'm working on building, again, less to be useful and more so I fully understand the build process (and how it has evolved and how to debug it) is FireFox 74 (and its contemporary corresponding Thunderbird). Attempting builds on 10.6/10.7 and my work Apple Silicon Mac run into countless problems...but the build ALMOST finishes on an Intel MacBook running 10.14...there, the sole problem seems to be with part of FireFox that is written in Rust (a new language, not C or C++) related to their "Servo" project (somehow?). My best guess is the Rust compiler I have is likely too new, and the language (a moving target) has changed since FireFox 74. Things that were legal then just aren't anymore, specifically with declaring certain types of "literal variables" (whatever those are!). I'm going to try hacking it and learn a little Rust in the process. Or...if that part of FireFox is optional, which would be great, disable it. FYI There seems to be a related(?) project, also called "Servo", which is a new browser entirely written in Rust. I've been able to build it on my work Apple Silicon MacBook (haven't tried on Intel due to lack of disk space!): https://en.wikipedia.org/wiki/Servo_(software) ---- I realize all this is beyond the scope of "System 7" which this site is supposed to focus on, but I think it will dovetail with my Classilla attempts (which also is not System 7!)...and I hope is interesting to you guys. Please let me know if you want me to shut up about it! (Or at least talk less...)
Last Edit: June 27, 2024, 16:27 by lauland
|
cballero
|
1024 MB Posts: 1176 System 7, today and forever
Reply #23 on: June 27, 2024, 23:06
|
This site delves in and out of the System 7 realm, but refocuses itself with each new thread..so tinker and share with no worries, for I am sure that besides me, we enjoy all of your exploits and musings! 
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #24 on: June 28, 2024, 17:27
|
I figured as much, but did want to let anyone who might be irritated by all the talk of Intel and Apple Silicon to speak up (and tell me to speak less!). (Still, please do exactly that, anyone!) For the record, it looks like the problems with FireFox 74 on modern (ie 10.14 or newer) systems is that Rust has evolved (with my machines too new). In particular the way "macros" are defined...which I at first thought were equivalent to C/C++ preprocessor #define macros, but on further looking, seem much more similar to C++ templates. (They look a LOT like function defs, including a header and an "Impl" body). The syntax is quite bizarre to my non-Rusty eyes! (But closer to C/C++ than to something more alien like Python). It looks like the use of Rust is MUCH more extensive also, not just being in the "servo" folder, but also in gfx/webrender, where it is used for gpu acceleration. It also looks like it was possible to disable the Rust parts in earlier versions, but not in this one. It looks like everything except for the Rust parts builds. I'm also having no luck getting the current Firefox (version 129) to build on 10.14, since it requires the MacOS 15 SDK. I copied it over and am trying to get my XCode to use it, but no dice so far. ---- So, the takeaway from this and the other efforts is it is extremely difficult to build FireFox/Mozilla on systems too far out of date from the when the source was released...I know, I know...this should have been obvious with a project that evolves so quickly...browsers are probably the fastest evolving software we use today...but, I'd hoped SOME backwards compatibility was conserved. I need to look into checking out older branches...it might be possible, if I'm clever enough, to find ones that correspond to the various OS's I have on my various machines...ie what exactly was the version that was current when MacOS 10.14 was current? Or 10.7? Or I can go the other direction and figure out which OS...and compiler...and install those. But something like finding and getting an older version of Rust for my 10.14 machine may be a pain... ---- So...enough of all that...on to Classilla next!
Last Edit: June 28, 2024, 17:29 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #25 on: July 02, 2024, 21:08
|
Classilla progress... I'm going to try building on three machines at the same time...that way if one "acts funny" I'll know it is isolated there. Sheepshaver, MacOS 9.0, 256m ram (ss does not support virtual), two partitions, one for system and apps, second for codewarrior, build tools and Classilla source. G4 "Mystic" aka gigabit, with the 400 mhz cpu card from a sawtooth, since I still haven't found the right driver for the dual g4 card. 2g ram, two partitions, separate System Folder from Classic, but it also has Tiger on it. USB 2.0 card for transfers. PowerMac 7600, MacOS 9.1 (but will likely switch to same 9.0 System Folder the above two use), with 500mhz g3 sonnet upgrade, 128m ram but will see if I can fit more in it. Single partition. USB 2.0 card. (It will be interesting to compare the G4 vs 7600's speeds) ---- I used the "official" Classilla binary to download the various tools and libs from the Floodgap gopher server. Am in the process of setting them up in the correct places. I'll upload/share the build environment once I have it fully set up to the point of compiling, but it'll end up being quite large, definitely 2g+, so don't know best where to share. Let me know if you have suggestions. NOTE: I really wish I'd looked at the Floodgap server before, it turns out it has a lot of the same parts/libs that I'd needed to find myself for Goliath and Jabbernaut!
Last Edit: July 02, 2024, 21:12 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #26 on: July 03, 2024, 04:28
|
Quote from: lauland I'll upload/share the build environment once I have it fully set up to the point of compiling, but it'll end up being quite large, definitely 2g+, so don't know best where to share. Let me know if you have suggestions. Considering how important a web browser effort is for the original Mac OS, I'd say you can, without any worry, host it on the Macintosh Garden like you did before with the other projects. However, rather than using the existing Classilla page, to keep this gargantuan and ambitious (yet doable) project separate enough, I'd recommend creating a new page for it. Also because its name would have to be changed, but even without the new name, the page could be titled, for example, "Classila (Unofficial Builds)", which can easily be edited later to whatever you may want to call it later, e.g. "Platinum Surfer" (Mac OS platinum theme + Silver Surfer? ).About the file size, it is common for the Garden to host numerous DVD rips and other such images, which go into 4GB+, and in some cases even dual-layer DVDs, going into 8GB+. So don't worry about that. It does take a really good while to upload DVD-sized files to the Garden, though, and it might take a few tries. If you prefer, you could alternatively upload it on MediaFire, GitLab or similar, but IMO that would be less ideal. Anyway, looking forward to see how that goes!
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #27 on: July 04, 2024, 21:37
|
Yeah, I think it would be something like this: https://macintoshgarden.org/apps/the-unofficial-tenfourfox-toolkit I kinda like something "Silver/Platinum Surfer" for a working name. It even implies the age of the hardware it will run on and/or its users! I wanted to be cautious and not count my chickens (etc) but the effort might as well have a name, makes it easier to refer to...and even if I don't finish completely (not counting those dang chickens...) even a half done collection of all the parts in one place is REALLY useful, and other people could/might pick up the torch... ---- Dang, I've been spoiled by USB3 and the speed of modern machines...not for compiling (I'm realistic about that), but just copying so many files between three machines is hella slow, even worse with the flash drives I was using. I've switched to a traditional external usb solely because I trust I know when it hits bad sectors, makes noises when it is actually doing something, and is easily replaced. I've got a firewire card, that might work well in the 7600, and will test net transfer... And both IDE and SATA sonnet cards that might make the 7600 build more tollerable...or even disk access on the G4 better... Copying a few large files is fine, but it's the thousands and thousands of tiny ones that make up CodeWarrior, the source, and all the other parts than easily takes at least an hour... A sync tool that I actually trusted would be VERY VERY nice...but...I'm at the point where I've spent so much time just setting the machines up...and could waste endless more perfecting them...I'm itching to set up Perl and the modules, and the ToolServer setup, etc. I think I'll allow myself one more stab at getting the Dual G4 card working and then just call that a lost cause. The mounting standoffs and screws for the sawtooth cpu card don't quite match what my mystic has and/or is missing due to the PowerLogix card it came with, so it is hanging there by friction! I'm going to either work on that a little more, so I'm not afraid of frolicking cats knocking into the machine and it falling off...or just set the G4 on its side... But like I said, all of us just love mucking with old hardware, and I could do it endlessly... ---- Ran into loads of trouble, bordering on the comical (to me at least), trying to use the same System Folder on the G4, the 7600 and SheepShaver. I wanted to do this because I wanted to make sure any CodeWarrior, MPW, and Perl preferences/settings, extensions, versions of AppleScript blah blah blah were the same, but will probably just try copying those by hand... The 7.1/7.2 updaters get confused if you have CodeWarrior installed anywhere but the default...not sure how critical having all the patches is to the build process... And now I'm like, ok, which machine are you going to sit down at and actually use? SheepShaver still, sadly, feels sluggish on my (lower end) MacBook Pro...I could always waste(?) even more time (how much?) setting it up on my higher end desktop windows machine... The G4 would seem obvious, even just with the 400 mhz card (which feels SO slow in MacOS X compared to the dual G4!), but the 7600 with the 500 mhz G3 is quite speedy, even with a slower older motherboard architecture, gives it a run for the money...with a pci Radeon and a SATA card it might rock, a bit...but again, more endless mucking... I do want to make snapshots/backups at as many points as possible to be able to back out. But that can be done at the end of each hack session, etc...
Last Edit: July 05, 2024, 06:49 by lauland
|
Bolkonskij
|
Administrator 1024 MB  Posts: 2023
Reply #28 on: July 05, 2024, 07:39
|
Good idea about integrating the backup at the end of each session. Have you looked into using Amend, maybe ? I'd start coding away on the 7600 because I'd love the authentic 90's coding feeling it would provide, but then that is just me :-) of course, you could always hop onto another during the dev process if you'd feel like ? Watching this one with interest ... good luck! :-)
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #29 on: July 05, 2024, 20:11
|
Another possibility, @lauland... perhaps you can try sniping a Mac Mini G4 (1.42GHz model recommended, but any will do). It's easy to work on, to set up, occupy very little space, is super light to move around, find to purchase, and usually can be gotten cheap... With patience, it can appear for 20 USD / Euros, or go as high as, say, 100. Usually it's in-between. Super high-end PPC G4 machine that boots into Mac OS 9.2.2 natively (thanks to the folks from Mac OS 9 Lives!).
|
|
Pages: 1 [2] 3 4 5
|
| |||||||||||||||
|
© 2021 System7Today.com. |
