Re: Modern browsers on OpenBSD for PowerPC?

> On Feb 19, 2024, at 3:41=E2=80=AFPM, George Koehler =
<[email protected]> wrote:
>=20
> On Sun, 18 Feb 2024 05:11:49 +0800
> Sergey Fedorov <[email protected]> wrote:
>=20
>> Could someone say what is the current state of *modern* web browsers =
for
>> PowerPC?
>=20
> All 3 major engines are broken on powerpc or powerpc64:
>=20
> - 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=E2=80=99t 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.
>=20
> [1] https://marc.info/?l=3Dopenbsd-ports&m=3D170725239028843&w=3D2
>=20
> 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=C3=A4rkl <[email protected]> wrote:
>=20
>> last time I tried, netsurf from ports worked fairly well.
>=20
> I have been using M-x eww in emacs--gtk3 on macppc, which can load
> only simple websites, but is better than nothing.
>=20
> 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 <[email protected]> wrote:
>=20
>> If so, from your MacPorts maintenance, I can imagine that you have =
the=20
>> required hardware. If you don't, in the following weeks, I could =
setup a=20
>> G4 tower and give you ssh access to it so you could leave Firefox=20
>> building on it.
>=20
> 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.
>=20
> 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.
>=20
> 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.