Picked up an iMac G5 the other day, so have spent today importing CDs for my old second gen iPod, surfing forums via Aquafox whilst listening to music on iTunes, and playing the odd game of Return to Castlewolfenstein. Mostly been enjoying how clean Tiger is, compared to the bloat in modern OS X.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
What have you done with a PowerPC today?
- Thread starter 2984839
- Start date
- Sort by reaction score
Is it possible to get Discord to run on a Tiger through an IRC, or something similar? I tried it in Snow Leopard and it worked, and I think Leopard and it ran. This was a couple of years ago.
There is `abaddon` (in my PPCPorts), which will probably not build on 10.4 due to something being broken on the way (possibly can be hacked by dropping non-essential features) and `discord-lite`, which will not build from source due to this, but presumably pre-built app will work.
There were a couple of other ones introduced here on MacRumors (this and another recent one, but no source code for it). I guess you rather try and see.
Tried Bitlbee? https://www.bitlbee.org/
You will likely need a secondary machine to be the server for this.
Does this open up the possibility of porting Bun for an actually usable JavaScript runtime? edit: I guess you'd need to support JSC and a modern Zig toolchain too so probably not...
Last edited:
I wasn't able to get abaddon to build on Tiger, but @Matias_ made a PR (not merged currently) to PowerPC ports that helped the build get further. If you want to jump in and help get it working on Tiger, that would be great. Dependencies are broken or not depending on the commit your macports source is set to (currently bash is broken, but if you go back half a year you can grab a working version.
Otherwise, discord lite might work, as @barracuda156 said. A download link is here: https://macintoshgarden.org/apps/discord-lite
Edit: This may be a more recent version, but idk if it is for 10.5+: https://dosdude1.com/apps/
You may be interested in quickjs (or quickjs-ng) which works all the way back to Tiger. Currently the chawan browser, which should work on 10.6 (and perhaps 10.5), uses it as its Javascript runtime.
Quickjs is reasonably performant. On a 2005 Powerbook G4 it can solve the Youtube Javascript challenges needed for yt-dlp in a couple of minutes.
Last edited:
Where? https://github.com/macos-powerpc/powerpc-ports/pulls
I do not see anything pending from him.
Just to clarify, chawan does not use quickjs port, it uses bundled and patched code of quickjs. elinks-devel now does use quickjs.
P. S. Did you get Nim working on Tiger?
I was referring to the PR he closed: https://github.com/macos-powerpc/powerpc-ports/pull/30
Today is the first day of a six day work week for me, so I haven't gotten Nim working and likely won't for a while. When I starting working on it, I would run into a function which has a slightly different name but the same function on Tiger, and have to #ifdef #define _ _ #endif the function. Then I would clean and restart the build, get a little further, and run into something else along the same lines. And since Nim takes a while (double digit minutes) to clean and extract, fixing it is a process I will need quite a bit of time for. Hopefully I will have a PR to fix that by March or so - there is just so much other stuff on Tiger that is higher priority or easier to fix for me.
Thanks for clarifying on chawan, and good to know about elinks-devel. Elinks-devel will probably build on Tiger should someone need a browser with modern Javascript support (I think I recall the non-devel version building), though for most purposes Aquafox is likely to remain the best overall browsing experience.
Re Nim.
It could be problematic if there is a lot of stuff failing. Nim uses C sources to bootstrap itself initially and then rebuilds with Nim sources, so it is needed to fix both, if it is done manually. The right way though is to fix Nim source and regenerate C source. Portfile has links to related issue (unfortunately, official documentation is lacking/incorrect for this). You don’t need to regenerate sources on powerpc, it can be done on any arch. If you will work on this, let me know, I describe the procedure which worked for me.
It is probably counter-productive to waste your time (or cpu cycles at least) on iterative attempts to build it. Perhaps give me an idea what fails, so that I can add fixed and regenerate C code.
FWIW, on Leopard it built with no issues from my portfile (from PPCPorts), though I am not sure at the moment ppc64 is working correctly.
Well, I do agree that an exotic lang with [currently] a single dependent is not among top priorities.
My idea was that all langs must be fixed – to facilitate development. Not much development happening, LOL, but why knows. The realized benefit of fixing obscure langs is likely small to none.
As of now, I did not see a real replacement for GUI browser (and this is true for modern macOS as well).
However, it is likely that some tasks may be easier in a TUI one, and possibly sites broken in Aquafox may be working in some TUI browser.
I am interested to know how elinks performs, if you get time to try, it is a small thing to build.
When I get back to the computer I was trying build Nim on next weekend, I can pass you the patch I working on. I believe the issue is Tiger is pickier about public/private function calls or variables, and considers some of the ones Nim uses to be private. I suppose I could do one of those patches that greps through the source code replacing all of the known instances of something Tiger considers private with the corresponding public function/variable.
Sadly, the Powerbook I have with me now has a 32 GB drive (really <30), so it can't realistically build big langs.
Yeah, there are quite a few langs which are broken on Tiger (like erlang) and while they probably aren't hard to fix, the benefit to fixing them is small enough I am unlikely to bother. Unless someone writes the next killer app in erland lol.
Chawan was just an interesting enough concept that I thought Nim was worth some effort. Though tbh, I should probably put that effort into porting a UXP based browser to 10.4 instead. Is the White Star branch of PowerPC Ports worth trying to build from?
On the topic of web browsers, elinks-devel brings in a bunch of dependencies that are broken on Tiger. Luckily, they are trivial to fix (just use gmake!). I submitted PRs to fix those that needed it. Elinks-devel calls execinfo.h if configured with backtrace, so I turned that option off and made the PR.
As for how it performs... it isn't a CPU hog, for what that's worth. It did print a bunch annoying error messages on my screen, but those go away. On macintoshgarden.org, it is useable. On something more complex like nintendolife, not so much. Thanks for your work on it, it has value, though I doubt there are too many sites it would work better on than Aquafox.
Apple had trouble trying to both be ANSI/POSIX/XOPEN_SOURCE compliant and also to enable all the functions that the system supported and people/software expected to find. Also, functions would slightly change their calling parameters and returned parameters based on new UNIX standards.
In the 10.4 headers they used a macro called __DARWIN_UNIX03 to enable the newer behaviour. Much/most software expects the newer behaviour, so you often need to define that.
MacOSX-SDKs/MacOSX10.4u.sdk/usr/include/stdlib.h at 041600eda65c6a668f66cb7d56b7d1da3e8bcc93 · phracker/MacOSX-SDKs
A collection of those pesky SDK folders: MacOSX10.1.5.sdk thru MacOSX11.3.sdk - phracker/MacOSX-SDKs
github.com
To get the full list of available functions, you often have to turn off the POSIX standard set by some software in their headers, source, or build systems, is disable _ANSI_SOURCE and _POSIX_C_SOURCE by setting them to 0 or otherwise not setting them at all.
MacOSX-SDKs/MacOSX10.4u.sdk/usr/include/stdlib.h at 041600eda65c6a668f66cb7d56b7d1da3e8bcc93 · phracker/MacOSX-SDKs
A collection of those pesky SDK folders: MacOSX10.1.5.sdk thru MacOSX11.3.sdk - phracker/MacOSX-SDKs
github.com
In the LegacySupport headers, we sometimes would define these functions ourselves because of this:
time.h: Declare localtime_r, gmtime_r, etc on Tiger · macports/macports-legacy-support@fce543b
Certain system functions on Tiger are not declared in the presence of _ANSI_SOURCE, _POSIX_C_SOURCE, or _XOPEN_SOURCE. This behavior can be difficult to work around in source because _XOPEN_SOURCE ...
github.com
This was, all in all, a rather huge PITA to work around, so in 10.5 Apple said "Stuff this" and just set up their own macro called _DARWIN_C_SOURCE to disable all the ANSI, POSIX, XOPEN_SOURCE, etc stuff that was frustrating everyone. This macro is almost always defined when building on MacOS on 10.5+ , so that is why things work more easily there.
eg:
MacOSX-SDKs/MacOSX10.5.sdk/usr/include/stdlib.h at 041600eda65c6a668f66cb7d56b7d1da3e8bcc93 · phracker/MacOSX-SDKs
A collection of those pesky SDK folders: MacOSX10.1.5.sdk thru MacOSX11.3.sdk - phracker/MacOSX-SDKs
github.com
Now, things would be much simpler when building on Tiger if you could just build against the 10.5 SDK and target MacOSX 10.4. Apple designed the system to be able to do that, and it does work if you are building on a 10.5+ system, to target 10.4. However, I was never able to reliably get software to build on 10.4 against the 10.5 SDK. There was always some kind of issue with the libgcc underpinnings and it would never link correctly.
That problem could presumably be solved with more effort expended. I ran out of time for that, so it was easier to just add more workaround to the 10.4 SDK instead, frustrating as that could get.
