Created attachment 256902 [details] nyxt Unhandled LOAD-FOREIGN-LIBRARY-ERROR in thread #<SB-THREAD:THREAD tid=101117 "main thread" RUNNING {1100BA0133}>: Unable to load any of the alternatives: ("libwebkit2gtk-4.1.so.0" "libwebkit2gtk-4.1.so" "libwebkit2gtk-4.0.so.37" "libwebkit2gtk-4.0.so") Builds done under poudriere (interactive jail: # find /usr/local -name "libwebkit2gtk-4.1*" /usr/local/lib/libwebkit2gtk-4.1.so /usr/local/lib/libwebkit2gtk-4.1.so.0 /usr/local/lib/libwebkit2gtk-4.1.so.0.16.7 # pkg-config --cflags webkit2gtk-4.1 -I/usr/local/include/webkitgtk-4.1 -I/usr/local/include/gtk-3.0 -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/at-spi2-atk/2.0 -I/usr/local/include/at-spi-2.0 -I/usr/local/include/atk-1.0 -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/libepoll-shim -I/usr/local/include/fribidi -D_THREAD_SAFE -I/usr/local/include/pixman-1 -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/gio-unix-2.0 -I/usr/local/include/libsoup-3.0 -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include Somehow nyxt fails to find it.
- Patch co-authored by Vasily Postnicov <shamaz.mazum@gmail.com>
Is that a runtime error or it happens while building nyxt?
(In reply to shamaz.mazum from comment #2) building under poudriere
(In reply to Nuno Teixeira from comment #3) I cannot see the cause of this error. This is what's happening under the hood: int main () { void *handle = dlopen ("libwebkit2gtk-4.1.so.0", RTLD_GLOBAL | RTLD_NOW); printf ("%p\n", handle); return 0; } Can you build it with clang and run it in your building environment (i.e. poudriere testport with -i flag) to make sure it produces non-null pointer? CFFI calls SB-ALIEN::DLOPEN-OR-LOSE when opening a library. You can try to trace it with (TRACE SB-ALIEN::DLOPEN-OR-LOSE) to see if it gives you some valuable information.
I thought there are some search paths for libraries in SBCL, but it simply passes library names to dlopen: CL-USER> (trace sb-alien::dlopen-or-lose) (SB-SYS:DLOPEN-OR-LOSE) CL-USER> (asdf:load-system :cl-webkit2) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libglib-2.0.so.0" :NAMESTRING "libglib-2.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X80074D408) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libgthread-2.0.so.0" :NAMESTRING "libgthread-2.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039B6408) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libgobject-2.0.so.0" :NAMESTRING "libgobject-2.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039B6808) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libgio-2.0.so.0" :NAMESTRING "libgio-2.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039BC008) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libgdk_pixbuf-2.0.so.0" :NAMESTRING "libgdk_pixbuf-2.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039BCC08) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libcairo.so.2" :NAMESTRING "libcairo.so.2" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039BE008) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libpango-1.0.so.0" :NAMESTRING "libpango-1.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039C4808) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libpangocairo-1.0.so.0" :NAMESTRING "libpangocairo-1.0.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039C8008) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libgtk-3.so.0" :NAMESTRING "libgtk-3.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039C8808) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libgdk-3.so.0" :NAMESTRING "libgdk-3.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8039C8C08) 0: (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"libwebkit2gtk-4.1.so.0" :NAMESTRING "libwebkit2gtk-4.1.so.0" :HANDLE NIL :DONT-SAVE NIL)) 0: SB-SYS:DLOPEN-OR-LOSE returned #.(SB-SYS:INT-SAP #X8088F0008) T
(In reply to shamaz.mazum from comment #4) > Can you build it with clang and run it in your building environment (i.e. > poudriere testport with -i flag) to make sure it produces non-null pointer? Are you saying that this could be related to the fact that webkit2 in ports being built with gcc?
Created attachment 256925 [details] readelf -d ./lib/libwebkit2gtk-4.1.so
(In reply to Nuno Teixeira from comment #6) (...) Maybe you can share your readelf results from your compile with clang and compare with "official" ports (uploaded readelf.txt). I can have no way to compile webkit2 port with clang due to cxx API still at 1, etc. Maybe soon we can open a upstream PR and link it to this one too. Cheers
(In reply to Nuno Teixeira from comment #6) > Are you saying that this could be related to the fact that webkit2 in ports being built with gcc? This is what comes to mind. I am just guessing. I ment this tiny program: int main () { void *handle = dlopen ("libwebkit2gtk-4.1.so.0", RTLD_GLOBAL | RTLD_NOW); printf ("%p\n", handle); return 0; } Does it work in your compile environment? I suggest to compile it with clang because SBCL is compiled with clang.
Created attachment 256927 [details] readelf -d /usr/local/lib/libwebkit2gtk-4.1.so
(In reply to shamaz.mazum from comment #9) (poudriere interactive jail on nyxt port) # cat test.c #include <stdio.h> #include <dlfcn.h> int main () { void *handle = dlopen ("libwebkit2gtk-4.1.so.0", RTLD_GLOBAL | RTLD_NOW); printf ("%p\n", handle); return 0; } # clang -o test test.c # ./test # 0x6a1ca826008 Note: if I change dlopen ("libwebkit2gtk-4.1.so.0" -> dlopen ("TEST-NOEXIST" result: # 0x0
Very strange! And what (sb-alien:load-shared-object "libwebkit2gtk-4.1.so.0") gives in SBCL repl? Does it return normally or signal an error?
(In reply to shamaz.mazum from comment #12) SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (sb-alien:load-shared-object "libwebkit2gtk-4.1.so.0") #P"libwebkit2gtk-4.1.so.0" * (sb-alien:load-shared-object "libwebkit2gtk-4.1.so") #P"libwebkit2gtk-4.1.so"
Created attachment 256932 [details] poudriere build log
(In reply to Nuno Teixeira from comment #13) All seems to be normal. I think I'll try to reproduce this error locally using FreeBSD's ports without my modifications and a standard base.txz I think I'll answer on the next week. Can you also provide options for sbcl package which is used in the build?
(In reply to shamaz.mazum from comment #15) Ok, thanks a lot for help on this. I will proceed to test build locally (outside poudriere) and do poudriere testports on 14.2 and 13.4 releases so I can check if error occurs in all. sbcl with default options: pkg info sbcl sbcl-2.5.0_2,1 Name : sbcl Version : 2.5.0_2,1 Installed on : Thu Jan 23 14:06:33 2025 WET Origin : lang/sbcl Architecture : FreeBSD:15:amd64 Prefix : /usr/local Categories : lisp lang Licenses : BSD2CLAUSE, PD Maintainer : krion@FreeBSD.org WWW : https://sbcl.sourceforge.io/ Comment : Common Lisp development system derived from the CMU CL system Options : CCL : off COMPRESSION : on DOCS : on GARBAGE_COLLECTOR: off LINKABLE_RUNTIME: off QSHOW : off SAFEPOINT : off SBCL : on SIMD : off THREADS : on UNICODE : on XREF : off Shared Libs required: libzstd.so.1 Annotations : FreeBSD_version: 1500030 build_timestamp: 2025-01-15T10:27:00+00:00 built_by : poudriere-git-3.4.99.20250109 repo_type : binary repository : poudriere
Aloha, i had written the port for Nyxt also some months ago, but it's still idling around. You really need to add this line: RUN_DEPENDS= xclip:x11/xclip Otherwise, you can't copy paste :D Besides this, i had the exact same issue. Before the update, i could compile everything. If i tried the flavored patch of Webkit with the new version, i hit the same issue. So it seems to be something with it. I also checked my old buildlogs since June 2024 and i think you are onto something. Every old webkit version that worked was compiled with clang. Every new webkit version which was not found was build with GCC. Is there any reason for the switch? How can i test the compilation of webkit with clang best?
(In reply to Torsten Zuehlsdorff from comment #17) Hello, gcc could be a reason for webkit not being detected. Also found something related but very vague: https://github.com/atlas-engineer/nyxt/issues/107 Related to build webkit with clang in FreeBSD ports: D45878: Consolidate, flavourise, update. USE_GCC because D35327 [1]. [1] https://reviews.freebsd.org/D35327 Shamaz already have a clang webkit version for some time now and it seems that you have success with it too. We trying to get nyxt working with current ports state.
Can you add this patch to the set of patches and try again? Also, can you please verify that nyxt is working?
Created attachment 257006 [details] Build fix
To clarify, this was indeed a problem with GCC.
(In reply to shamaz.mazum from comment #21) Nice! Will this add "--eval '(sb-alien:load-shared-object "libwebkit2gtk-4.1.so")'" be used only for our ports workaround (webkit/gcc)? Should upstream be aware of this fix to improve their config/build in such cases? Hope that I can test this today because my main builder pordriere jail is failing on me... Cheers!
(In reply to Nuno Teixeira from comment #22) Hard to say. Sometimes they accept patches which fix FreeBSD-related problems, sometimes not. It's up to you to decide. Also, building Nyxt does not mean it is going to work. So checking that first is the priority. I cannot help you here, obviously, I am still on that altered ABI :) BTW, one of accepted FreeBSD patches is this: https://github.com/atlas-engineer/nyxt/commit/676360bf4af6f25b8d6913dc784ced201e937ed4 We need to check if it is stil actual. With modern WebKit versions I cannot reproduce that problem anymore (with this commit being reverted). So if nyxt works with the recent patch, I'll ask you to check another patch, OK?
> Hope that I can test this today because my main builder pordriere jail is failing on me... I just put it on mine. ;) > Should upstream be aware of this fix to improve their config/build in such cases? They should at least be aware of it. Not sure if the fix is good for a broad audience, but it is at least worth a mention in the build-doc.
Also when I compare our Makefiles, I have some differences: I have RUN_DEPENDS= xclip:x11/xclip because otherwise you can't copy & paste from/into nyxt. I also have a USES for gstreamer, since the documentation states, that it is used for- video support. Not sure why it's not in your version. Maybe its just, because my last version is 3.11.7 and not 3.12.0.
(In reply to Torsten Zuehlsdorff from comment #25) I'm aware of gstreamer dependency needs as I am following www/badwolf example. At this point I can't do a testport or run-test due to poudriere build problems in my machine. But please, if you already have a working and complete port, upload it here, commit and take maintainership if needed. Cheers!
When using your line: > --eval '(sb-alien:load-shared-object "libwebkit2gtk-4.1.so")' \ The build fails with: ===> Building for nyxt-3.12.0 makefile:36: *** recipe commences before first target. Stop. ===> Compilation failed unexpectedly.
(In reply to Torsten Zuehlsdorff from comment #27) What do you mean by "using my line"? Have you used patch(1)? Asking just to be sure, that the patch is applied correctly. I double checked, it seems that I posted the patch correctly.
(In reply to Torsten Zuehlsdorff from comment #27) Uh, sorry. You need to place the patch in files/ ;)
Created attachment 257025 [details] The patch file > Uh, sorry. You need to place the patch in files/ ;) No need to be sorry. I am a ports-comitter, i was aware of this :) Attached is the patch file i generated with "make makepatch" after the standard procedure. If I remove the patch, the port compiles but does not find Webkit. If I add the patch, I get the error message described above. If you need something compiled / tested, just let me know. I have a poudriere good server for this :)
(In reply to Torsten Zuehlsdorff from comment #30) But the patch you have attached misses "Space backslash" at the end of the line it should be: + --eval '(sb-alien:load-shared-object "libwebkit2gtk-4.1.so")' \ It's a regular makefile syntax, as I guess. That patch I have attached is already generated with `make makepatch`. So no need to call it again, just place it in "files" directory of the port. Sorry again for not providing instructions. Anyway, please make sure that two characters (space and backslash) are present at the end of the line.
Created attachment 257027 [details] v1 builds fine: https://people.freebsd.org/~eduardo/logs/nyxt/nyxt_v1-3.12.0.log Now we have all needed to do some run-testing. TODO: - check if https://github.com/atlas-engineer/nyxt/commit/676360bf4af6f25b8d6913dc784ced201e937ed4 is needed - add xclip - add gstreamer
(In reply to Nuno Teixeira from comment #32) --- +RUN_DEPENDS= xclip:x11/xclip +OPTIONS_DEFINE= GSTREAMER +OPTIONS_DEFAULT= GSTREAMER +GSTREAMER_USES= gstreamer +GSTREAMER_USE= GSTREAMER=bad,good,libav --- v1: run-test blank screen + core dump % nyxt www.freebsd.org Nyxt version 3.12.0 <INFO> [12:54:47] Source location: #P"/usr/local/share/nyxt/" <INFO> [12:54:47] Listening to socket: #P"/var/run/xdg/nunotex/nyxt/nyxt.socket" <INFO> [12:54:47] Loading #P"/home/nunotex/.local/share/nyxt/history/default.lisp". <INFO> [12:54:47] Restoring 1 buffer from history. eglExportDMABUFImageMESA failed eglExportDMABUFImageMESA failed <INFO> [12:54:48] Loading #P"/home/nunotex/.local/share/nyxt/auto-rules.lisp". <WARN> [12:54:48] Warning: Error in FFI method: Couldn't execute "xdg-open": No such file or directory eglExportDMABUFImageMESA failed eglExportDMABUFImageMESA failed $ dmesg pid 36106 (WebKitWebProcess), jid 0, uid 1001: exited on signal 11 (core dumped) I will apply upstream PR, upload port with missing deps and new logs and run-test
Created attachment 257029 [details] v1.1: add xclip + gtreamer deps v1.1: - add xclip - add gtreamer NOTE: https://github.com/atlas-engineer/nyxt/commit/676360bf4af6f25b8d6913dc784ced201e937ed4 is already merged in 3.12.0
Later on I will do some tests on www/badwolf related to updating it to use webkit 4.1 instead of 4.0. Last test that I did it displayed a blank page too. I will test it and check if a relation exists.
(In reply to Nuno Teixeira from comment #34) Good to hear that there is some progress. Is nyxt just unstable or completely unusable? If WebKit crashes when you close a buffer, you may want to try these patches: https://github.com/shamazmazum/freebsd-ports/blob/39eddfdee7e727dbd95837bafd05236148fa1a61/www/webkit2-gtk3/files/patch-Source_WebCore_platform_graphics_PlatformDisplay.h https://github.com/shamazmazum/freebsd-ports/blob/39eddfdee7e727dbd95837bafd05236148fa1a61/www/webkit2-gtk3/files/patch-Source_WebCore_platform_graphics_PlatformDisplay.cpp It's seems to be the same atexit bug which I reported for clover: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240761 > NOTE: https://github.com/atlas-engineer/nyxt/commit/676360bf4af6f25b8d6913dc784ced201e937ed4 is already merged in 3.12.0 I mean, we can try to revert it. It's a dirty workaround for old WebKit versions.
(In reply to Nuno Teixeira from comment #34) BTW, trivial-clipboard also supports x11/wl-clipboard (for wayland users). So if you are on wayland, you need to add it in place of xclip. Myself, I removed all that clipboard machinery from Nyxt and just use GTK for copy-pasting ;)
Created attachment 257033 [details] v1.2: add extra patch to revert 676360bf4af6 (disabled) - add extra patch to revert 676360bf4af6 (disabled) Did a test-run with revert applied and same errors on console, blank page. Revert patch is turned off by default but it can be usefull for further tests. See Makefile. Also I'm investigating "eglExportDMABUFImageMESA failed" on www/badwolf with webkit 4.0. Same error on console and blank page. Maybe there is more applications failing with "eglExportDMABUFImageMESA failed" on webkit apis 4.0 and 4.1. I will forget 6.0 api for now.
(In reply to Nuno Teixeira from comment #38) Nyxt's manual says: <Start quotation> Blank WebKitGTK views When experiencing rendering issues, try to disable compositing as below: (setf (uiop/os:getenv "WEBKIT_DISABLE_COMPOSITING_MODE") "1") <End quotation> That can be done with usual setenv in tcsh, of course. Like adding this to .login: setenv WEBKIT_DISABLE_COMPOSITING_MODE 1
(In reply to shamaz.mazum from comment #39) But I never needed it
(In reply to shamaz.mazum from comment #40) env WEBKIT_DISABLE_COMPOSITING_MODE=1 nyxt https://www.freebsd.org Opens freebsd site! We can have some real run testing now! Thanks!
(In reply to shamaz.mazum from comment #39) I did a quick research on WEBKIT_DISABLE_COMPOSITING_MODE=1 and all relates to webkit and graphics drivers possibly issues like this, e.g., https://github.com/NixOS/nixpkgs/issues/32580 Also, www/badwolf is fixed same way on webkit 4.0 api. From this point some work will be needed to check other ports status.
(In reply to shamaz.mazum from comment #37) > BTW, trivial-clipboard also supports x11/wl-clipboard (for wayland users). So > if you are on wayland, you need to add it in place of xclip. > Myself, I removed all that clipboard machinery from Nyxt and just use GTK for > copy-pasting ;) Are you saying that no external program is needed like xclip or wl-clipboard? Could you give an practical example on how to copy-paste?
(In reply to Nuno Teixeira from comment #43) No-no. I was talking about my personal fork :) When using upstream version, I think you have to install either xclip or wl-clipboard.
(In reply to Nuno Teixeira from comment #42) Just one more check: www/epiphany (4.1 api) - shows eglExportDMABUFImageMESA failed - runs without WEBKIT_DISABLE_COMPOSITING_MODE=1 needs
Run-test: Getting some js errors loading: www.wirple.com (nice for some graphics benchs) www.facebook.com <INFO> [12:40:34] Loading "https://facebook.com/". <WARN> [12:40:36] Warning: JavaScript error: GError: Domain: "WebKitJavascriptError", Code: 601, Message: Unsupported result type <WARN> [12:40:36] Warning: Web process terminated for buffer 5721 (opening https://www.facebook.com/) because it crashed Can you share results on your machine?
(In reply to Nuno Teixeira from comment #46) > www.facebook.com Opens for me but asks whether I want to accept cookies or not. This dialog is continuously reloaded again and again. Finally that website says: You’re Temporarily Blocked It looks like you were misusing this feature by going too fast. You’ve been temporarily blocked from using it. No JS crashes whatsoever. > www.wirple.com When I click "HTML 5 3D benchmark" it starts drawing cubes, more and more of it. It says something like "the next test starts when you fps is below 10". My FPS were far above 10 for a long time, so I closed it at the first test. Can you check how other WebKit-based browsers (like MiniBrowser) work with facebook? I cannot check MiniBrowser because it does not have proxy settings to circumvent censorship.
(In reply to Nuno Teixeira from comment #46) Also, asking just out of curiosity, do you have WebKitWebProcess crash when closing any buffer in nyxt?
(In reply to shamaz.mazum from comment #48) Yes, I am: <snip> <INFO> [20:38:17] Loading "https://wirple.com/". ** (WebKitWebProcess:3339): WARNING **: 20:38:17.525: The GStreamer FDK AAC plugin is missing, AAC playback is unlikely to work. <WARN> [20:38:17] Warning: Web process terminated for buffer 5720 (opening https://www.wirple.com/) because it crashed $ dmesg pid 3339 (WebKitWebProcess), jid 0, uid 1001: exited on signal 11 (core dumped) Both MiniBrowser(s) 4.0 and 4.1 are failing on facebook and wirple: % /usr/local/libexec/webkit2gtk-4.1/MiniBrowser https://www.facebook.com eglExportDMABUFImageMESA failed ** (MiniBrowser:3270): WARNING **: 20:30:38.419: WebProcess CRASHED % /usr/local/libexec/webkit2gtk-4.1/MiniBrowser https://www.wirple.com eglExportDMABUFImageMESA failed ** (WebKitWebProcess:3277): WARNING **: 20:30:58.639: The GStreamer FDK AAC plugin is missing, AAC playback is unlikely to work. % /usr/local/libexec/webkit2gtk-4.0/MiniBrowser https://facebook.com eglExportDMABUFImageMESA failed ** (MiniBrowser:3286): WARNING **: 20:32:31.893: WebProcess CRASHED % /usr/local/libexec/webkit2gtk-4.0/MiniBrowser https://wirple.com eglExportDMABUFImageMESA failed ** (WebKitWebProcess:3293): WARNING **: 20:32:46.912: The GStreamer FDK AAC plugin is missing, AAC playback is unlikely to work. ** (MiniBrowser:3290): WARNING **: 20:32:47.394: WebProcess CRASHED $ dmesg (lots of) pid 3339 (WebKitWebProcess), jid 0, uid 1001: exited on signal 11 (core dumped)
(In reply to Nuno Teixeira from comment #49) Have you tried this patch? https://github.com/shamazmazum/freebsd-ports/commit/55636ca19a5bfb9665f6f24146335306f36d706d It solves the problem with crashes after closing a buffer for me.
(In reply to Nuno Teixeira from comment #49) > eglExportDMABUFImageMESA failed Also I do not have this line. > ** (WebKitWebProcess:3277): WARNING **: 20:30:58.639: The GStreamer FDK AAC plugin is missing, AAC playback is unlikely to work I have this but I think it's OK.
(In reply to shamaz.mazum from comment #50) Just to clarify: for me WebKitWebProcess crashed in one of atexit(3) handlers. It may be the same with GCC build.
(In reply to shamaz.mazum from comment #50) I'll test it later on and share results. Also very important: https://lists.freebsd.org/archives/dev-commits-ports-all/2025-January/146213.html
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=904a1e9137d6aaa7e438c79b4c9392176f915cbf commit 904a1e9137d6aaa7e438c79b4c9392176f915cbf Author: Nuno Teixeira <eduardo@FreeBSD.org> AuthorDate: 2025-02-01 15:31:27 +0000 Commit: Nuno Teixeira <eduardo@FreeBSD.org> CommitDate: 2025-02-01 15:35:53 +0000 www/nyxt: New port: Keyboard-driven web browser which uses WebKitGTK backend Nyxt is a keyboard-driven web browser designed for hackers. Inspired by Emacs and Vim, it has familiar keybindings (Emacs, vi, CUA), and is infinitely extensible in Lisp. WWW: https://nyxt.atlas.engineer/ Co-authored by: shamaz.mazum[at]gmail[dot]com PR: 284258 www/Makefile | 1 + www/nyxt/Makefile (new) | 33 ++++++ www/nyxt/distinfo (new) | 3 + www/nyxt/files/patch-source_start.lisp (new) | 10 ++ www/nyxt/pkg-descr (new) | 3 + www/nyxt/pkg-plist (new) | 164 +++++++++++++++++++++++++++ 6 files changed, 214 insertions(+)
Committed without run depends on xclip as I can copy-paste from/to nyxt, firefox, sterm (i3). Didn't add pkg-message about using WEBKIT_DISABLE_COMPOSITING_MODE=1 env workaround as there are people that don't need it. I will leave PR open until webkit2-gtk works are still up. Thanks!
(In reply to Nuno Teixeira from comment #55) > Didn't add pkg-message about using WEBKIT_DISABLE_COMPOSITING_MODE=1 env workaround In my opinion, it's better to add a note that you *may* need to set that env variable (if you see a white screen). People who do not need that workaround, will do nothing, and people who need it will know what to do. Otherwise, it's hard to find the info. Personally, I use that hack, otherwise the UI starts to freeze after a while (this also can be added in the note).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=a81273e68fd6d97f5f2f3ee49d16314bd4e64cfc commit a81273e68fd6d97f5f2f3ee49d16314bd4e64cfc Author: Nuno Teixeira <eduardo@FreeBSD.org> AuthorDate: 2025-02-01 18:23:07 +0000 Commit: Nuno Teixeira <eduardo@FreeBSD.org> CommitDate: 2025-02-01 18:26:02 +0000 www/nyxt: Add pkg-message Add a message about using WEBKIT_DISABLE_COMPOSITING_MODE=1 workaround. PR: 284258 Reported by: shamaz.mazum[at]gmail[dot]com www/nyxt/Makefile | 1 + www/nyxt/pkg-message (new) | 10 ++++++++++ 2 files changed, 11 insertions(+)
(In reply to shamaz.mazum from comment #56) Done, thanks.
Closing PR. Thanks all!