|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Building firefox/mozilla/etc from source (Read 94888 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 676 Symtes 7 Mewconer! |
on: June 15, 2024, 21:49
Throughout the years I've always loved having the source of the software I actually use everyday. Both so I can see what it actually does, and how it works, and learn from that, but also so I know what is actually running on my computer. From time to time that included only running a version of Mozilla/Firefox that I compiled myself. Unfortunately I've been inconsistent with this, but always saved snapshots of my build folders. "I'll get back to that one day..", etc, but never did. Every time I upgraded my OS...or compiler...or macports/homebrew...or whatever, things tended to break spectacularly, and it just wasn't worth it. Just being able to say, "Why, yes, I only use browsers I build myself", was cool, but it's only really exciting for the Geekiest of Geeks. ---- So now I'm revisiting this...and more, thinking I really want to build (and use) the last Classzilla and TenFourFox where they were left off. Heck, the best browser (or at least most compatible with modern ssl) I've found, currently, for my 10.4 G4 machines is some mutant called "ArticFox". Can't remember where I got it, but I really should find its source too! Anyway, I figured you guys'd be interested, want to follow along, have suggestions, and/or can share your own experiences. ---- With that said, I started with an old "moilla-central.tar.gz", I'd been carrying around on a flash drive, that I remember thinking was good. It turned out to be QUITE old unfortunately. From the "obj-x86_64-apple-darwin10.8.0" folder, I could tell I last built in for 64 bit Intel 10.6.8. (Handy hint, subtract 4 from the first number in the Darwin version to get the x in 10.x.y...so 10-4 from "10.8" gives "10.6.8"). Try #1 was on a 10.6.8 MacBook...which failed due to it surprising me by being an "Intel Core Duo" and not an "Intel Core2 Duo"...so 32 bit only. And updating macports (or heaven forbid) homebrew to get what was needed is quite daunting. Try #2 was on a different 10.7.x MacBook I knew was 64 bit (or it wouldn't run 10.7!)...but my macports/homebrew had far too many weird things with it's versions of glib, gtk, and python...again, VERY painful trying to update macports/homebrew! Try #3 on the same MacBook, but running 10.6.8, worked flawlessly. I believe it may have the same macports/homebrew that I'd used back in the day. It turned out to be FireFox 8.0alpha1, but, hey, first steps, eh? Trying to build the same source on modern systems, where macports/homebrew is still supported, and I could just add whatever I needed, didn't go as well...things like glib/gtk were too new, and python support for things like Mercurial (similar to csv/git but way out of favor these days) were very sticky. ---- I've got a handful of other old snapshots, some a lot newer, some a lot older, and am trying to get ALL of them to build on some Mac or other. (In the middle of hacking some sort of gtk 1.2 on modern Macs as part of it, right now, to build the OLD ones). I'm also trying the current version of FireFox on my modern Mac, but, again, having lots of python/homebrew/macports "fun"! But I'm going to stick with it until I really am only using a browser I compiled myself. ---- What got me started, and interested again in this sort of thing THIS time is "Servo" which is a FireFox project, a new browser written in Rust, still at the very early stages, but very interesting. Not up to everyday use yet, by far, but I'm going to try and keep up with it's development this time... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: June 15, 2024, 21:54 by lauland
|
lauland
|
512 MB Posts: 676 Symtes 7 Mewconer!
Reply #1 on: June 16, 2024, 04:46
|
Update: The problems building that particular version of FireFox on 10.7 were NOT due to macports, but actually changes between 10.6 and 10.7. I can see a LOT of errors about things with names starting with NS_ not being defined (deprecated in Lion?) and or simple things like not being able to find exit() (probably moved to a different header, or it needs to include something it isn't). Going by the size of the obj_* folder, it gets about half of it compiled. So, a crazy idea I have is since XCode on Lion includes the 10.6 sdk, I'll try a build that way... On the 32-bit 10.6, the problem turns out there is NO macports installed. It looks like it might build with a "sudo port selfupdate" and then I can try installing all the same packages the 64-bit version has. That may take a long time since it'll likely have to build everything from source, but will give it a try... ---- Not that building Firefox 8.0a for Intel is the point (especially for something useless like 32-bit Intel)...the point is getting my chops back up to speed building ANY FireFox on Mac! And this is just one of the six or so completely unlabeled old snapshots I kept...
Last Edit: June 16, 2024, 04:57 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #2 on: June 16, 2024, 14:29
|
Building Classilla 9.3.4b has been one of those many ideas I also had that don't generally move beyond the idea stage... But we definitely could benefit from that so that we could "steer the web ship" again under Mac OS proper, that is, Mac OS 9.2.2 and earlier. I believe by default it is to be built with CodeWarrior Pro 7.1. Wanna port it to CW Pro 6 and compile it for 68k? Just kidding. :-P What manner of 68k hardware would even be able to dream of running it? Maybe one of those "Vampire" FPGA ones, I guess... So maybe if people put those in their 68k Macs. I guess it's as crazy as running Bochs on 68k (which, by the way, is available). Oh, and Carbon is also on the way, hence the Mac OS 8.6+ requirement even for PPC. Of interest, there's a download bug in Classilla that seems easy to fix, but requires us to have a "compiling environment" first. So getting it to compile as is would be the first step.
Last Edit: June 16, 2024, 14:32 by Jatoba
|
lauland
|
512 MB Posts: 676 Symtes 7 Mewconer!
Reply #3 on: June 17, 2024, 01:02
|
Classzilla: Damn straight! On my TODO list... I got the 32 bit 10.6 FireFox 8.0a build working...just had to rebuild macports. Again, not useful, but to prove I'm understanding the moving parts. It looks like the macports I have on my 10.7 macbook was originally from a 10.6 install...so I'm rebuilding it all now...sigh... Found the source for a version of ArcticFox...in the readme it says at least 10.6 is required...this either means the PPC one I am actively using on my 10.4 ibook was cross compiled, or probably more likely, I need to find an older version that supported builds on 10.4. Also on the TODO list: I grabbed the "unofficial tenfourfox toolkit" for Tiger and Leopard. It comes with preinstalled macports env that already includes everything needed and much more. I've got a big multi-processor G4 desktop I'm going to try building on. ---- MacPorts hints for me to remember (not just for building mozilla/firefox): "selfupdate" is your friend. Do it if it tells you your ports are old. If it errors out, just run it again, repeat/etc, until everything is finally updated. (This is because during the selfupdate, it will update things like tcl or python, etc, which macports is at least partially written in, so the selfupdate can fail until EVERY SINGLE THING is updated. Always include "-v", to actually see what the port command is doing. "sudo port -v upgrade outdated" should also be done. Taking a look at packages.macports.org shows they no longer provide binaries for PPC, and ones for older versions of MacOS X on Intel are quite sparse too, so on those systems expect things to "selfupdate" or "upgrade" from source...ie take a LONG time. Again, if you try installing ANYTHING and it fails, make sure you've done "selfupdate" and "upgrade outdated" first. The "port select" command will let you create generic "bin" links for packages like clang, llvm, and, most importantly, since they aren't supplied by apple, "python2" and "python3" commands. By putting /opt/local first in your path you can use this to selectively override either homebrew or older versions that come with MacOS.
Last Edit: June 17, 2024, 02:06 by lauland
|
cballero
|
1024 MB Posts: 1186 System 7, today and forever
Reply #4 on: June 17, 2024, 22:32
|
On the what to run a 68k version of Classilla in question: Possibly virtually, under emulation on modern hardware, so it can benefit from the strength of a fast processor. (a nice touch might be to 3D-print a Classic Mac case like the Macintosh TV or retrofit it inside an original or Lamp iMac case for kicks to help recapture part of the original Mac flair)
|
wove
|
1024 MB Posts: 1366
Reply #5 on: June 18, 2024, 00:34
|
I have used both HomeBrew and MacPorts for sometime. They are not mutually exclusive and you can install both without problems. MacPorts operates like the Linux compatibility layer in BSD, while HomeBrew tries to make Linux(open source material) to run like a native application. HomeBrew is built using Ruby, while MacPorts is built with Python. I install Zim (a wiki style notebook that I really like) using HomeBrew and it runs and looks like a native Mac Application. Install Zim with HomeBrew runs in Windows and looks just like it does on Ubuntu. For my newest system that Apple still supports I stick almost exclusively with HomeBrew, for older systems and PPC systems MacPorts is the way to go. MacPorts does a very nice job of layering in updates to software that is part of the BSD subsystem. It updates ssl and such to keep security a bit closer to current. MacPorts is also excellent for update command line tools and applications. Htop, neofetch, lspci and such can easily be added. Both HomeBrew and MacPort will keep themselves and the software they install current and up to date. Both have excellent documentation. Both will pull in the latest Xcode command line tools from Apple if you have a developer account. If you are fond of keeping old OS X hardware up running and safe, MacPorts is very much worth exploring. Both can add potent software to the system and help keep up with security.
|
lauland
|
512 MB Posts: 676 Symtes 7 Mewconer!
Reply #6 on: June 18, 2024, 03:45
|
Absolutely what you guys said... Of course if I get Classzilla building for PPC, I will set up projects for m68k...assuming it isn't too insane of thing to do, I won't be able to resist trying! (No idea how feasible it is yet, of course...it may require a newer CodeWarrior than what can build m68k apps...but then I can always try a mutant install like I did for Goliath...) Yes, you can absolutely have both macports and homebrew...but I do caution you that if you do so, try and keep duplicates between them to a minimum. I've found homebrew likes to be more cutting edge (both what it supports and what it includes), while macports will have still have much older versions of software. (A good example is Python 2.x). If you have the same package installed in both, but different versions, you can end up REALLY confusing yourself...depending on which you have before the other in your $PATH. Pre-Apple-Silicon homebrew also installs all over your /usr/local and can be hard to remove and/or install without leaving bits all over the place. On Apple-Silion, it goes in /opt where it should have always been! ---- So, I'm having some strange problems with macports on 10.7...doing selfupdate (or even just "port sync" to get the latest list of packages) will break a working macports install badly. I've got several snapshots of /opt from when 10.7 was my daily driver, but all of them break after updates. This is in sharp contrast to my experience with 10.6 (on the SAME machine), which I was able to even get the 32-bit Intel version going with no problems at all. I'm probably doing something silly and will catch myself soon...or maybe not? Could be known bugs? Have to research... ---- Was able to build the current dev firefox (version 129) on my M2 work laptop very smoothly, once I figured out the confusion with python and Mercurial. It built VERY quickly, for such a beast and seems very stable. It calls itself "Nightly.app" and uses a separate profile, so you can't (easily) switch between one you built and a stock download. I'm hesitant to switch to it as my standard browser, but I don't think I should be...we'll see... Once I had the most recent FireFox building, I wanted to build Thunderbird (FireFox's email client sibling), which I use for some accounts (to keep personal separate from work where I'm forced to use Outlook). Was very surprised that I immediately ran into problems with the bootstrap script failing to download the "mozilla-unified" source via Mercurial...but since it really is the same source base as FireFox with the addition of the "comm" folder and a single line in mozconfig, I got it set up manually...only to be told my XCode which included the MacOS 14.2 SDK was too old! So I need to upgrade my OS and then also XCode...very irritating, but par for the course if you're trying to keep up with the latest versions. I might see if I can get an older source tree...one that corresponds with the ThunderBird binary I use everyday...but I know very little about Mercurial and checking out different branches, compared to git...
Last Edit: June 18, 2024, 03:51 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #7 on: June 18, 2024, 10:16
|
Quote from: cballero On the what to run a 68k version of Classilla in question: Actually, yes, that counts, good thinking. This is exactly what happened with Blah Blob!: super fun, great game made in HyperCard in 2023, but only high-end PPC hardware (i.e. Mac mini) runs it properly, whereas the 68k Macs are stuck at 1 or 2FPS, maybe less. But 68k Mac emulators can run it OK, best if run from Mini vMac in particular. So in that sense, yes, bring forth the 68k Classzilla!
|
lauland
|
512 MB Posts: 676 Symtes 7 Mewconer!
Reply #8 on: June 18, 2024, 15:40
|
The macports fun I was having on 10.7 was because I was trying to build ArcticFox, which requires ccache among other things, that I didn't have installed. I'm going to try again, but on 10.6. Classilla m68k: I counted at least 200 .mcp project files in the tree, so just converting THOSE to m68k will be a major undertaking! It might be scriptable...it looks like the .xml export versions are included...they could be hacked and then use an applescript to import them into codewarrior and save again as .mcp... It is built using codewarrior 7.1, so right off the bat, we're talking a mutant codewarrior install. I'd use the IDE from 7.1 with the plugins from 6.x. Maybe mixing and matching runtime/msl/macos libraries. It uses shared libs, with stubs for linking, so that'd need CFM-68k without radically changing things.
|
cballero
|
1024 MB Posts: 1186 System 7, today and forever
Reply #9 on: June 19, 2024, 02:39
|
Seeing 'Mac-Scientists' at work is phenomenally thrilling, to say the least!!! 
|
ClassicHasClass
|
32 MB Posts: 39
Reply #10 on: June 20, 2024, 17:53
|
I guess this is the part where I show up to mention a few things. If you haven't done so already, I would strongly advise you get Classilla (no Z) building without modifications first so that you understand how the build process works and how it can go wrong. It's an intimidating process the first couple times through. - Making it run without CFM-68K would be an incredible undertaking and I doubt it would even get off the ground even if you got it to link. Just assume now that you'll have shlbs. I never got the static build operational even on PPC. - You might want to get the debug build to work so you can have standard error output, though I never finished it myself. There's only so much you can figure out in the debugger. - To get it to run on anything before 8.5, you'll need to remove dependencies on OS Unicode support (probably mostly in NSPR and the apprunner, some in widget, possibly other places). - It definitely needs Open Transport. There may be other OS dependencies that I've not previously noticed. - The XML files are very, very old. They are guaranteed to not be current with the MCPs; I reorganized a number of them and rewrote a few from scratch. If you decide to use them as a basis, be prepared to do a lot of manual merging. If you do make this work, as a courtesy please name it something other than Classilla so people don't think I'm supporting it.
Last Edit: June 20, 2024, 17:56 by ClassicHasClass
|
ClassicHasClass
|
32 MB Posts: 39
Reply #11 on: June 20, 2024, 17:55
|
(dupe)
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #12 on: June 20, 2024, 19:02
|
Quote from: ClassicHasClass Classilla (no Z)[...] I was thinking that maybe Classzilla (with the "z") would be a great name for the forked effort. But of course, whoever does all the heavy lifting, or all the lifting (@lauland presumably in either case), ought to choose what to name it. For now I was going along with the name, because I remember that same request from your Classilla page to rename it. I believe likewise the logo will also have to change, as was done for the TenFourFox forks. Or, maybe "Classzilla" would be still too similar. Maybe something else? Is @lauland open for ideas? Moofzilla? Some non-zilla name?
|
cballero
|
1024 MB Posts: 1186 System 7, today and forever
Reply #13 on: June 21, 2024, 07:20
|
All excellent points!!!  The paths of least resistance.. keeping it with CFM-68k and OT would be ideal, then removing the modern dependencies are all givens.. and as far as the name and icon change, well, a bunch of folks here can help out with at very least, some ideas for the name Perhaps a color change to the icon to give a nod at the inspiration for this new build? Still, to have a pre-8.5 and still a more up-to-date browser would be simply phenomenal, and 68k as well? Why that would be, 'insanely great!' now wouldn't it? 
|
lauland
|
512 MB Posts: 676 Symtes 7 Mewconer!
Reply #14 on: June 21, 2024, 18:24
|
I think there are some horses that need to be held! @classichasclass has pointed out a few things I feared would be true, and thinking about a name and/or icon for something purely theoretical is really jumping the gun, and, probably, overestimating my abilities, too... With that said, I'll of course start a try, but it sounds like even getting working cfm-68k .mcp files would be the required first step, and a MAJOR pain since there are literally hundreds of them. (Doubly so with a mutant m68k binary producing codewarrior 7.1) Even building the thing normally as-is for PPC is an undertaking, and, for sanity's sake, the "zeroth" step. Wait until I've done that at the very least.
|
|
Pages: [1] 2 3 ... 5
|
| |||||||||||||||
|
© 2021 System7Today.com. |
