So, it looks like on ArchLinux aarch64 (ARMv8 64bit) there's a `js38` package but it's not directly usable, it's just a gjs dependency: https://archlinuxarm.org/packages/aarch64/gjs
However, it looks like pretty much everything I've tried on aarch64 platform is broken, everything but Weston/Wayland, beside the fact that as soon as I reach the top left corner the Raspberry Pi crashes ... and I have similar Shenanigans with GNOME on an Asrock D1800M with an embedde Celeron. Regardless, I've meanwhile betrayed GTK+ with QtWebEngine and realized Qt also doesn't work on aarch64 TL;DR it looks like aarch64 is in a very unstable stage and bugs to report everywhere would be so many I'd ask vacations just to file them. Not what I am meant to spend my time right now, apologies. However, if this is of any interest to anyone: 1. WebKitGTK+ is very slow to bootstrap compared to both Electron and WtEbEngine (Chromium based) 2. even enabling all the settings via GJS it doesn't provide Hardware acceleration like Chromium based alternative do 3. I can watch Full HD Youtube videos on a Raspberry Pi 2 via QtWebEngine, **no way** I can do the same with WebKitGTK+ The current state of WebKitGTK+ on platforms where it's most compatible is very sad, if it's extremely inferior in terms of performance in the most common SBC such Raspberry Pi, I wonder how come it's deployed so much even on ARMv6 (ARMv11) 'cause it's very greedy on RAM too. Apologies for the rant, it's just 3 days I'm trying to watch a bloody Web video through an SBC that is fully HW accelerated by Mesa and OSS. Best Regards On Thu, Aug 3, 2017 at 12:41 AM, <philip.chime...@gmail.com> wrote: > Hi Andrea, > > Thanks for reporting this in any case! Would you mind opening a bug on > bugzilla.gnome.org too so others can subscribe and/or suggest patches > there? > > I don't really have an aarch64 system to test anything on, so it's good > that you found this. Did you build mozjs38 yourself or use some > distribution's packaged version? What happens if you run mozjs's built-in > shell, does that work at all? (It's called "js38" and might be found in the > devel package) > > Regards, > Philip > > On Wed, Aug 2, 2017 at 5:16 PM Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> Trying WebKitGTK+ bootstrapped by GJS on ArchLinux for ARM and everything >> is fine in both Raspberry Pi 0, 1, 2, and 3 ... but the 3 only if I run the >> ARMv7 (32bit) architecture. >> >> On ARMv8 (64bit) as soon as I type GJS I have a core-dumped with no other >> message whatsoever. >> >> Is this a known issue? >> >> $ gjs --version >> gjs 1.48.6 >> >> $ uname -a >> Linux alarm 4.12.4-1-ARCH #1 SMP Thu Jul 27 21:54:16 MDT 2017 aarch64 >> GNU/Linux >> >> >> $ gjs --verbose >> (gjs:425): Gjs-ERROR **: option parsing failed: Unknown option --verbose >> Trace/breakpoint trap (core dumped) >> >> $ gjs >> Segmentation fault (core dumped) >> >> >> >> journalctl -xe shows these errors: >> >> Process 425 (gjs) of user 1000 dumped core. >> >> Stack trace of thread 425: >> #0 0x0000fffbe0f01950 raise >> (libc.so.6) >> #1 0x0000fffbe0f018dc raise >> (libc.so.6) >> #2 0x0000fffbe1224e20 >> g_log_default_handler (libglib-2.0.so.0) >> #3 0x0000fffbe1225020 >> g_logv (libglib-2.0.so.0) >> #4 0x0000fffbe122523c g_log >> (libglib-2.0.so.0) >> #5 0x000000000040187c main >> (gjs-console) >> #6 0x0000000000401df8 >> _start (gjs-console) >> #7 0x0000000000401df8 >> _start (gjs-console) >> -- Subject: Process 425 (gjs) dumped core >> >> >> >> Process 433 (gjs) of user 1000 dumped core. >> >> Stack trace of thread 433: >> #0 0x0000ffff753771f8 n/a >> (libmozjs-38.so) >> #1 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #2 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #3 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #4 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #5 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #6 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #7 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #8 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #9 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #10 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #11 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #12 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #13 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #14 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #15 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #16 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #17 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #18 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #19 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #20 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #21 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #22 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #23 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #24 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #25 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #26 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> #27 0x0000ffff765c06c0 n/a >> (linux-vdso.so.1) >> >> Stack trace of thread 434: >> #0 0x0000ffff74f8d3a0 >> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >> #1 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #2 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #3 0x0000ffff756778d4 n/a >> (libmozjs-38.so) >> #4 0x0000ffff7414a708 n/a >> (libnspr4.so) >> #5 0x0000ffff74f86ffc >> start_thread (libpthread.so.0) >> #6 0x0000ffff75f8f9ec >> thread_start (libc.so.6) >> >> Stack trace of thread 435: >> #0 0x0000ffff74f8d3a0 >> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >> #1 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #2 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #3 0x0000ffff756778d4 n/a >> (libmozjs-38.so) >> #4 0x0000ffff7414a708 n/a >> (libnspr4.so) >> #5 0x0000ffff74f86ffc >> start_thread (libpthread.so.0) >> #6 0x0000ffff75f8f9ec >> thread_start (libc.so.6) >> >> Stack trace of thread 437: >> #0 0x0000ffff74f8d3a0 >> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >> #1 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #2 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #3 0x0000ffff756778d4 n/a >> (libmozjs-38.so) >> #4 0x0000ffff7414a708 n/a >> (libnspr4.so) >> #5 0x0000ffff74f86ffc >> start_thread (libpthread.so.0) >> #6 0x0000ffff75f8f9ec >> thread_start (libc.so.6) >> #0 0x0000ffff74f8d3a0 pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >> #1 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #2 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #3 0x0000ffff756778d4 n/a >> (libmozjs-38.so) >> #4 0x0000ffff7414a708 n/a >> (libnspr4.so) >> #5 0x0000ffff74f86ffc >> start_thread (libpthread.so.0) >> #6 0x0000ffff75f8f9ec >> thread_start (libc.so.6) >> >> Stack trace of thread 438: >> #0 0x0000ffff74f8d3a0 >> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >> #1 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #2 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #3 0x0000ffff756778d4 n/a >> (libmozjs-38.so) >> #4 0x0000ffff7414a708 n/a >> (libnspr4.so) >> #5 0x0000ffff74f86ffc >> start_thread (libpthread.so.0) >> #6 0x0000ffff75f8f9ec >> thread_start (libc.so.6) >> >> Stack trace of thread 441: >> #0 0x0000ffff74f8d3a0 >> pthread_cond_wait@@GLIBC_2.17 (libpthread.so.0) >> #1 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #2 0x0000ffff741443ac >> PR_WaitCondVar (libnspr4.so) >> #3 0x0000ffff756778d4 n/a >> (libmozjs-38.so) >> #4 0x0000ffff7414a708 n/a >> (libnspr4.so) >> #5 0x0000ffff74f86ffc >> start_thread (libpthread.so.0) >> #6 0x0000ffff75f8f9ec >> thread_start (libc.so.6) >> Process 433 (gjs) crashed and dumped core. >> >> >> >> >> Thanks in advance for any sort of outcome. >> _______________________________________________ >> javascript-list mailing list >> javascript-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/javascript-list >> >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
