Mac 10.5 and PowerPC support

[barracuda156]

@rmottola From a quick look into the code it seems nothing much is gonna break PowerPC build – my concern was assembler in JIT, but apparently it is not implemented for PPC at all: https://github.com/rmottola/Arctic-Fox/tree/master/js/src/jit
Assuming Linux ppc32 does work as it is claimed, there is some arch-agnostic fallback?
Flags in mozcfg for it largely overlap with those which TenFourFox uses for Darwin ppc32:
https://github.com/rmottola/Arctic-Fox/blob/master/mozcfg-ppc32linux
vs
https://github.com/classilla/tenfourfox/blob/master/G5.mozcfg
TFF relies on 10.4 SDK though and archaic gcc 4.8. We do not need to be restricted by those for PPC. While 10.6 PPC SDK has certain limitations and does not match 10.6 x86 exactly, usually such incompatibilities are fixable. (Say, if GDC is used somewhere, a fallback with mach semaphores will be needed.)
Rust – which is broken on PPC – and some fancy options are disabled for 10.6 target anyway, as it is for x86.

Could you say, if there is anything apparent that may turn to be a major stopper?

[rmottola]

JIT ION for PPC is as specific TenFourFox feature. ArcticFox as welll as Firefox and others run interpreter on PPC, 32+64bit

Linux PPC is supported, except in last 42.0 version, where it is very unstable. Debugging welcomed.... with bisection from 41 series.

gcc 4.8 still works fine with ArcticFox, although newer gcc as well as clang are supported now, but beware with old MacOS SDK versions and newer compilers.

Major show-stopper is support for MacOS 10.5, since it is the last released PPC OS.
I have made several attempts to have ArcticFox work on 10.5 Intel, I get it as far as building, but then crash on startup.

So, I see quite some work to get ArcticFox on MacOS PPC. I tried myself several times, no success yet.

[barracuda156]

@rmottola Thank you for a detailed reply. Do you have a branch with your work on 10.5 support? That perhaps will be helpful.
We do have 10.6 for PowerPC (only 32-bit supported), but it is a rather early version, so the SDK differs.

PPC JIT seems to have been ported from TFF to AF, but I have no idea if it gonna work for the current versions.
https://github.com/wicknix/AF-OSX-PPC

New GCCs support Darwin PPC fine (in upstream), I am currently using 12.3.0. There is an issue which pops up time to time with malloc errors due to a duplicate libstdc++, but usually it is solvable.

[rmottola]

I pushed my current 10.5 work in a separate branch. Some patches are a work-around, some could be considered definitive.
In any case, for me, AF builds to completion, but then fails to run.

Please check
https://github.com/rmottola/Arctic-Fox/tree/mac10.5

[barracuda156]

@rmottola Thank you very much! I will give it a go.

Did you try starting it via GDB, is there some meaningful error? Or a crash log in Library/Logs/CrashReporter (or something similar, writing from memory now).

[rmottola]

Never been able to get a useful stacktrace with GDB in AF.
You need to build in debug mode and be sure no optimizations or stripping happens.

[barracuda156]

@rmottola I just looked into 10.5 branch, it is behind master by some number of commits, but does not have anything extra. Was everything merged? Which mozcfg did you use with it?

[rmottola]

I just did a master pull-up, it was up-to-date for 42.1 release when I published, don't worry. No significant MacOS changed. I didn't publish the mozconfig, it is derived from the 10.6 one. Will share that too.

[rmottola]

@barracuda156 10.5 branch was updated to current master. except a small glitch common to 10.6 support, it builds. But it has the same crash on startup issue.

[barracuda156]

@rmottola Thank you! I will try that. Sorry for a delay, too much stuff to handle in parallel.

[barracuda156]

@rmottola Seems that by now it is quite lagging. But let me give it a go.

P. S. On a side-note, referring to https://github.com/rmottola/Arctic-Fox/wiki/libc---for-MacOS-10.6 – there is a very experimental port of libc++ for PowerPC now: https://ports.macports.org/port/libcxx-powerpc
It will need gcc10+ to be usable, built with +stdlib_flag. It seems that gcc13 does not work well with earlier lic++ headers, so perhaps gcc11–12 will be a better pick.
It appears to be functional on basic level, but very likely will need some fixes to make it work (besides custom flag, of course).
AFAIU, Arctic-Fox does not support new gcc versions, so at the moment this cannot even be tried, but just FYI.

[barracuda156]

@rmottola Also, do you build against external ICU, nss etc. or not? Apparently TenFourFox only been setting --with-system-jpeg and building its own copies of every lib, but I tried to run the build of Arctic-Fox now, and it fails on linking ICU. Perhaps something wrong with build settings, but if external libs work, it will be easier, faster and with much more up-to-date dependencies.

[barracuda156]

I have set whatever noticed to --with-system-* and apparently it does not try to build ICU, or at least fails on different stuff :)

Looks like in order to make it work for PowerPC (by work I mean build, to begin with, whether it gonna actually work is left to be determined), a number of fix-ups are to be ported from TenFourFox master. I borrowed some, and will see how it goes. Hopefully only Cocoa stuff is broken and needs to be fixed.

[barracuda156]

@rmottola Oh wow, I bumped into ICE:

rs6000_secondary_reload_inner:17193, type = load
(parallel [
        (set (reg:V16QI 79 v2)
            (mem:V16QI (and:SI (reg:SI 0 r0 [orig:941 D.21530 ] [941])
                    (const_int -16 [0xfffffffffffffff0])) [0 MEM[(const uint8 *)_157 & 4294967280B]+0 S16 A128]))
        (clobber (reg:SI 13 r13))
    ])
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/media/libyuv/source/row_common.cc: In function 'void libyuv::NV12ToRGB565Row_C(const uint8*, const uint8*, uint8*, int)':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/media/libyuv/source/row_common.cc:1316:1: internal compiler error: in rs6000_secondary_reload_fail, at config/rs6000/rs6000.c:16984
 }
 ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://trac.macports.org/newticket> for instructions.
{standard input}:unknown:Undefined local symbol LC1
{standard input}:unknown:Undefined local symbol LC2
{standard input}:unknown:Undefined local symbol LC3
{standard input}:unknown:Undefined local symbol LC4
{standard input}:unknown:Undefined local symbol LC5
{standard input}:unknown:Undefined local symbol LC0
{standard input}:unknown:Undefined local symbol LC6
{standard input}:unknown:Undefined local symbol LC7
{standard input}:unknown:Undefined local symbol LC8
{standard input}:unknown:Undefined local symbol LC9
{standard input}:unknown:Undefined local symbol LC10
{standard input}:unknown:Undefined local symbol LC11
{standard input}:unknown:Undefined local symbol LC12
{standard input}:unknown:Undefined local symbol LC13
{standard input}:unknown:Undefined local symbol LC14
{standard input}:unknown:Undefined local symbol LC15
{standard input}:unknown:Undefined local symbol LC16
{standard input}:unknown:Undefined local symbol LC17
{standard input}:unknown:Undefined local symbol LC18
{standard input}:unknown:Undefined local symbol LC19
{standard input}:unknown:Undefined local symbol LC20
{standard input}:unknown:Undefined local symbol LC21
{standard input}:unknown:Undefined local symbol LC22
{standard input}:unknown:Undefined local symbol LC23
{standard input}:unknown:Undefined local symbol LC24
{standard input}:unknown:Undefined local symbol LC25
{standard input}:unknown:Undefined local symbol LC26
{standard input}:unknown:Undefined local symbol LC27
{standard input}:unknown:Undefined local symbol LC28
{standard input}:unknown:Undefined local symbol LC29
{standard input}:unknown:Undefined local symbol LC30
{standard input}:unknown:Undefined local symbol LC31

In the directory  /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/obj-ff-dbg/media/libyuv/libyuv_libyuv
The following command failed to execute properly:
/opt/local/bin/g++-mp-4.8 -flax-vector-conversions -fpermissive -O2 -mcpu=G5 -mtune=G5 -falign-loops=16 -falign-functions=16 -falign-labels=16 -falign-jumps=16 -read_only_relocs suppress -force_cpusubtype_ALL -mdynamic-no-pic -o row_common.o -c -fvisibility=hidden -fvisibility-inlines-hidden -DNDEBUG -DTRIMMED=1 -DCHROMIUM_BUILD -DUSE_LIBJPEG_TURBO=1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_REMOTING=1 -DENABLE_WEBRTC=1 -DENABLE_CONFIGURATION_POLICY -DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_HIDPI=1 -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1 -DUSE_SKIA=1 -DENABLE_TASK_MANAGER=1 -DENABLE_WEB_INTENTS=1 -DENABLE_EXTENSIONS=1 -DENABLE_PLUGIN_INSTALLATION=1 -DENABLE_PROTECTOR_SERVICE=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_BACKGROUND=1 -DENABLE_AUTOMATION=1 -DENABLE_PRINTING=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DHAVE_JPEG -DLIBYUV_DISABLE_AVX2 -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/media/libyuv -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/obj-ff-dbg/media/libyuv/libyuv_libyuv -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/media/libyuv/include -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/media/libyuv -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/obj-ff-dbg/ipc/ipdl/_ipdlheaders -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/ipc/chromium/src -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/ipc/glue -I/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/obj-ff-dbg/dist/include -fPIC -DMOZILLA_CLIENT -include /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/obj-ff-dbg/mozilla-config.h -MD -MP -MF .deps/row_common.o.pp -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wwrite-strings -Wunreachable-code -Wcast-align -Wno-invalid-offsetof -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -isysroot /Developer/SDKs/MacOSX10.6.sdk -fno-exceptions -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -DNO_X11 -maltivec -mabi=altivec -pipe -g -O3 -fomit-frame-pointer /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_www_arctic-fox/arctic-fox/work/Arctic-Fox-d47de016ca126fbb704adb4b49e862640f037c2d/media/libyuv/source/row_common.cc

[rmottola]

AFAIU, Arctic-Fox does not support new gcc versions, so at the moment this cannot even be tried, but just FYI.

Actually the issues are more on Mac and Apple Headers needing warning relaxation to compile. On Linux and BSD I can compile with modern GCCs up to gcc 12 as well as clang 7. I can compile with Clang 7.0 also on Mac 10.11 So you may play.

[rmottola]

I usually do not build with external dependencies on Mac, but it works. ICU, harfbuzz, nss can be externalized from system

[rmottola]

@rmottola Oh wow, I bumped into ICE:

For that I don't know, it could be a PPC specific issue. I suppose clang is still unusable on PPC.
You could try a different GCC version or reduce optimization. Try -O1. Less memory and CPU burden for testing anyway.

[barracuda156]

Actually the issues are more on Mac and Apple Headers needing warning relaxation to compile. On Linux and BSD I can compile with modern GCCs up to gcc 12 as well as clang 7. I can compile with Clang 7.0 also on Mac 10.11 So you may play.

Got it, thanks. I have built Palemoon now with gcc13, so yeah, it should work (I guess the codebase is pretty close).

(The biggest issue with GCC is a lack of support for ObjC stuff, but here perhaps no changes until gcc 15 or who knows.)

[rmottola]

No news from the GCC side for a while, I fear, nobody interested in enhancing their objc-2 support. However, TenFourFox hacked most of the stuff to be gcc 4.8 compatible. So we know where to look.
I tried on PowerPC 10.5. GCC 4.8 is quite old and needs further obj-c tweaks which I did not. I tried gcc 7, but that has issues elsewhere, in non-obj-c code. BindingUtils.h and strings.

[rmottola]

@barracuda156 I did some extra work to bring in 10.4 code which should also apply to 10.5 regarding fonts stuff using ATS.
I feared that AF is crashing due to font issues. In case, we can revert it in the future.
Unfortunately, it did not help. I generally updated the mac10.5 branch with latest dev, if you wish to try. Compiles, but still crashes before showing a window.

[barracuda156]

@rmottola Palemoon compiles with the new gcc, so there are fixes for that too, in a sense. It still needs to have some parts of code fixed though, since at the moment the app starts and hangs. There are gdb logs pointing to the issue here: dbsoft/White-Star#2

Given how much stuff has been fixed in GCC after gcc10 (including specifically for PowerPC), I think it is a non-viable approach to stick to archaic versions and waste time on hacking the code to adapt to gcc bugs which are fixed in the current versions. gcc7 is not supported with upstream, so nothing gets backported, and I think neither Iain nor Macports bothers with that either. We should really switch to gcc11+ for everything.

Edit: I should in fact rebuild my gcc13 soonish to pick the latest fix for ObjC from Iain.

[barracuda156]

@barracuda156 I did some extra work to bring in 10.4 code which should also apply to 10.5 regarding fonts stuff using ATS. I feared that AF is crashing due to font issues. In case, we can revert it in the future. Unfortunately, it did not help. I generally updated the mac10.5 branch with latest dev, if you wish to try. Compiles, but still crashes before showing a window.

Great! Yes, I will give it a try in a couple of days. Still stuck with fixing folly to run test suite on PowerPC. (But hopefully that will be complete tonight.)

P. S. And it looks like both browsers suffer from the same issue.

[rmottola]

@rmottola Palemoon compiles with the new gcc, so there are fixes for that too, in a sense. It still needs to have some parts of code fixed though, since at the moment the app starts and hangs. There are gdb logs pointing to the issue here: dbsoft/White-Star#2

Given how much stuff has been fixed in GCC after gcc10 (including specifically for PowerPC), I think it is a non-viable approach to stick to archaic versions and waste time on hacking the code to adapt to gcc bugs which are fixed in the current versions. gcc7 is not supported with upstream, so nothing gets backported, and I think neither Iain nor Macports bothers with that either. We should really switch to gcc11+ for everything.

MacPorts currently goes with gcc7 on Leopard and so do I, on Intel and PPC. On Intel however there is more recent Clang, so this is a relief.

[barracuda156]

It goes with gcc7 by default, yes, but gcc10+ works better. I have been using gcc13 for quite a while.
What is roughly needed is this: macports/macports-ports#16843 (that was closed for reasons unrelated to functionality as such; I will return to that in a while, but somebody on Macrumors already using it successfully on 10.5).

[rmottola]

I updated the 10.5 tree... it builds on intel 64bit, but crashes on startup, as always :)

[rmottola]

@barracuda156 updated 10.5 tree to latest dev code. Still aborts before opening first window. It spits out some JS stuff before... if I were better with gdb and gecko, maybe at least a ballpark of what is aborting could be determined

[barracuda156]

@rmottola Two quick questions:

1. Did you ever try building it with GTK backend on macOS? If that can work, it eliminates most if not all SDK compatibility issues, since GTK works fine, AFAICT.
2. I looked at Palemoon page, and apparently even the current versions do not need rust to build. Are there any reason to be constrained by 27.x here? (Sorry, if a silly question, I am just not aware of issues here.)

[rmottola]

@barracuda156 I did not try to build with GTK, I htink it would be a mess and an extra layer of stuff, especially then having gtk3 on 10.5... but if you want to try, go. TenFourFox goes native Mac and so does PaleMoon and Firefox, why should we change? also it works on 10.6 quite well!
Who is constrained by 27.x ? why do you even cite it? I do not understand

[barracuda156]

@barracuda156 I did not try to build with GTK, I htink it would be a mess and an extra layer of stuff, especially then having gtk3 on 10.5... but if you want to try, go. TenFourFox goes native Mac and so does PaleMoon and Firefox, why should we change? also it works on 10.6 quite well!

No doubt a native build is preferable. I am just not sure if it will work eventually. GTK-based browser would be still better than none at all :) But hopefully, of course, native one gets fixed.

Who is constrained by 27.x ? why do you even cite it? I do not understand

Perhaps I misunderstood a mention in the README, sorry.

[rmottola]

No doubt a native build is preferable. I am just not sure if it will work eventually. GTK-based browser would be still better than none at all :) But hopefully, of course, native one gets fixed.

If you wish, you can try and report how it goes.

Who is constrained by 27.x ? why do you even cite it? I do not understand

Perhaps I misunderstood a mention in the README, sorry.

27.x was starting point of code, sure, but we had like 35000 commits since then, getting patches from Mozilla and TenFourFox. The code definitely evolved, CSS and JS compatibility increased, but also porting becomes harder, since we tap into patches from Mozilla where 10.5 & 10.6 had long been deprecated.