> On Feb 19, 2024, at 3:41 PM, George Koehler <kern...@gmail.com> wrote:
> 
> On Sun, 18 Feb 2024 05:11:49 +0800
> Sergey Fedorov <vital....@gmail.com> wrote:
> 
>> Could someone say what is the current state of *modern* web browsers for
>> PowerPC?
> 
> All 3 major engines are broken on powerpc or powerpc64:
> 
> - www/chromium recently broke on i386, because it is now too big for
>   32-bit pointers.  It has no chance to run on powerpc.

The way to handle that is to peg the port for a select architecture/platform to 
the last working version.
That will get some years of meaningful functionality which is way better than 
having it just broken.


>  Other than
>   i386, I believe that only aarch64 and amd64 have ever completed a
>   chromium build, so powerpc64 seems unlikely.

This is surprising, to be honest, since ppc64 is supposed to work with V8 (not 
on macOS, but other ELF-using systems).
Though this is useless unless OpenBSD ppc64 itself is fixed for G5 to begin 
with.

> - www/mozilla-firefox needs a rust compiler, which is missing on
>   powerpc and crashes on powerpc64.  After you have rust, there might
>   be other problems.

Palemoon and Arctic Fox are non-Rust options. Those should be feasible and 
reasonably functional.

> - www/webkitgtk4 is broken in the powerpc bulk build report [1].
>   It is now a clang error, "failed to perform tail call elimination
>   on a call site marked musttail", but if someone fixed the error,
>   there might be other errors.  Older versions failed a static_assert
>   on powerpc.

This won’t save us, but static asserts are often just wrong for a 
non-mainstream archs since those who add them are unaware of correct alignment, 
padding etc. It may be worth simply commenting it out, and see how it goes 
further.

> webkitgtk4 is unreachable on powerpc64, because some
>   other packages are broken on powerpc64.
> 
> [1] https://marc.info/?l=openbsd-ports&m=170725239028843&w=2
> 
> OpenBSD/macppc uses the powerpc packages.  OpenBSD/powerpc64 only runs
> on PowerNV models (with OPAL firmware), not on a Mac.

Is it something fixable or not?

> The problem is elsewhere: qutebrowser needs x11/qt5/qtwebengine which
> is a fork of chromium; powerpc can't run chromium.  In your link, the
> check for "${PROPERTIES:Mrust}" correctly excludes powerpc.

I had an impression that Qt5 is only broken on macOS. Disappointing if this is 
so on BSD as well. But not something I am ready to try fixing from my side.

> On Sun, 18 Feb 2024 14:07:14 +0100
> Florian Märkl <open...@florianmaerkl.de> wrote:
> 
>> last time I tried, netsurf from ports worked fairly well.
> 
> I have been using M-x eww in emacs--gtk3 on macppc, which can load
> only simple websites, but is better than nothing.
> 
> Someone had proposed www/ladybird on ports, but I never looked at it.

There is also Nyxt, which is using Lisp, which works on ppc. But I think it 
also needs some chromium components now.
AFAIR it used webkitgtk2 before, that could potentially work.
(We need Kirll @catap feedback here, I will request him to respond.)

> On Sun, 18 Feb 2024 22:41:18 +0000
> Roberto Arturo Gonzalez Godinez <robglez...@proton.me> wrote:
> 
>> If so, from your MacPorts maintenance, I can imagine that you have the 
>> required hardware. If you don't, in the following weeks, I could setup a 
>> G4 tower and give you ssh access to it so you could leave Firefox 
>> building on it.
> 
> Don't try Firefox as long as there is no rust.  Linux or NetBSD might
> have rust on powerpc, but OpenBSD never did.

mrustc may become a workable choice, but needs gcc backend, at least for macOS.
Another one is gccrs, but not idea when it becomes generally usable. (I does 
work, judging from tests, but apparently is not yet able to build real-life 
Rust apps.)

> OpenBSD briefly had lang/rust on powerpc64, but it broke, and some
> other problems on powerpc64 are blocking a rust fix.  (Less than a week
> ago, I noticed that C++ exceptions are crashing on powerpc64.  Working
> C++ exceptions might unbreak gdb, so gdb can debug other problems.)

Is there a GitHub or bugzilla issue to track that?

> After rust has a package (on either powerpc or powerpc64), the next
> obstacle is devel/spidermonkey115, the JavaScript engine from Firefox
> 115.  It needs patches on powerpc64 and probably on powerpc.  (It was
> missing code to handle powerpc64's ucontext_t.)  If spidermonkey115
> has a package, then x11/gnome/gjs and devel/glade might get packages,
> which might unblock other stuff like xfce.
> 
> An attempt at www/mozilla-firefox would require at least bringing
> forward the spidermonkey patches.

If it does not rely on Rust in itself, I could take a look.

> www/webkitgtk4 is in the "parallel2" category, among the slowest
> packages to build.  A fast PowerPC Mac might take days to build it.
> I don't know, because the build now stops early at an error.
> 
> I would not build llvm (which is smaller than webkit) on a PowerPC
> Mac unless it had at least a 750 MHz cpu and 1G ram.  I want to build
> llvm, because I have a possible fix for a powerpc llvm bug.  My build
> might take around 4 days.  While I am busy with llvm, I am far away
> from wanting to build webkit.

It may be worth dumping LLVM/Clang in favor of GCC in fact, the latter has way 
better support for PPC and more reasonable upstream, in my experience.

Reply via email to