Bug 275914 - www/webkit2-gtk{3,4}: Flavorize?: Deal with 4.0, 4.1 and 6.0 SONAMEs
Summary: www/webkit2-gtk{3,4}: Flavorize?: Deal with 4.0, 4.1 and 6.0 SONAMEs
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-desktop (Team)
URL:
Keywords:
: 277526 (view as bug list)
Depends on:
Blocks:
 
Reported: 2023-12-24 15:19 UTC by Nuno Teixeira
Modified: 2024-03-06 16:23 UTC (History)
3 users (show)

See Also:
vishwin: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nuno Teixeira freebsd_committer freebsd_triage 2023-12-24 15:19:30 UTC
I'm new to this port and I'm looking for a roadmap to update it.

At the moment:
-gtk3 is using 4.0 API
-gtk4 is using 5.0 API 

- Flavorize dealing with 4.0, 4.1 and 6.0 APIs
  Inspired in OpenBSD port 2.42.4

### www/webkitgtk4/Makefile
### 
FLAVORS =               webkitgtk41 webkitgtk60
FLAVOR ?=

.if ${FLAVOR:Mwebkitgtk41}
API =                   4.1
WANTLIB += atk-1.0 gdk-3 gtk-3 soup-3.0
LIB_DEPENDS +=          devel/libsoup3 \
                        x11/gtk+3
CONFIGURE_ARGS +=       -DUSE_SOUP2=OFF \
                        -DENABLE_WEBDRIVER=OFF
.elif ${FLAVOR:Mwebkitgtk60}
API =                   6.0
WANTLIB += graphene-1.0 gtk-4 soup-3.0
LIB_DEPENDS +=          devel/libsoup3 \
                        x11/gtk+4
CONFIGURE_ARGS +=       -DUSE_SOUP2=OFF \
                        -DUSE_GTK4=ON
.else
API =                   4.0
WANTLIB += atk-1.0 gdk-3 gtk-3 soup-2.4
LIB_DEPENDS +=          devel/libsoup \
                        x11/gtk+3
CONFIGURE_ARGS +=       -DUSE_SOUP2=ON \
                        -DENABLE_WEBDRIVER=OFF
.endif
###

My first question is:
Why isn't 5.0 included in OpenBSD port?
Does 5.0 was superceded by 6.0?

Looking at this flavors, old and new software can pick API needed to work.

Thoughts are welcome.
Comment 1 Charlie Li freebsd_committer freebsd_triage 2023-12-24 17:58:46 UTC
4.0 and 4.1 SONAMEs are both GTK3, the only difference is the libsoup used. Only 4.0 uses libsoup (2), all others use libsoup3. Been a minute since I've looked at the GTK4 SONAMEs but last I checked it was 5.0. Not sure what constitutes 6.0 yet.

The bigger issue wrt flavourisation is packaging the documentation.
Comment 2 Charlie Li freebsd_committer freebsd_triage 2023-12-24 17:59:37 UTC
Quick glance later, SONAME 6.0 supersedes 5.0 entirely.
Comment 3 Nuno Teixeira freebsd_committer freebsd_triage 2023-12-24 18:36:54 UTC
It is clearer now, the best way to proceed will be working on both ports as it is now:

-gtk3: update and deal with 4.0 and 4.1 SONAMEs
-gtk4: update and deal with 6.0 SONAME
Comment 4 Olivier Duchateau 2023-12-25 18:04:12 UTC
I'm working on this update [1], [2].

Everything build fine until the 2.38.6 release. From 2.40.x and 2.42.x I'm encountering problems with LLVM (14, 15) and/or C++ functions. Build fails, full log is available here [3].

With GCC there is another problem, but build is ok.

On my laptop, WebKitGTK takes about 5 hours to build, and with the latest releases (2.40 and higher) we need a lot of RAM more than 8G.

The 6.0 API is available since the 2.40.0 release.

[1] https://codeberg.org/olivierd/freebsd-ports-gnome/src/branch/44/Mk/Uses/webkit.mk
[2] https://codeberg.org/olivierd/freebsd-ports-gnome/src/branch/44/www/webkit2-gtk3/Makefile
[3] https://codeberg.org/olivierd/freebsd-ports-wip/src/branch/master/logs/clang15-webkit2-gtk4-2.40.2.log
Comment 5 Nuno Teixeira freebsd_committer freebsd_triage 2023-12-25 19:12:41 UTC
(In reply to Olivier Duchateau from comment #4)

I will test [1] and [2] very soon. You added flavors for APIs :)
It will be nice because I maintain a port that is in need for 4.1 API to get updated.

> On my laptop, WebKitGTK takes about 5 hours to build, and with the latest
> releases (2.40 and higher) we need a lot of RAM more than 8G.

My i7-10750H /16GB laptop takes >6 hours building chromium, 1 poudriere job with all cores on it, tpmfs off and I got used to see swap being hit (hard sometimes).

2 hours on gcc12 with swap used at ~500MB and sometimes 1GB.

Impressive numbers.
Comment 6 Nuno Teixeira freebsd_committer freebsd_triage 2023-12-26 15:56:01 UTC
(In reply to Olivier Duchateau from comment #4)

I've just confirmed with openbsd webkit maintainer that they build it fine with clang 13 and 16 but not sure about specific clang patches applied to port.

I will start testports with your patches today and share results.
Comment 7 Olivier Duchateau 2023-12-27 09:16:26 UTC
To easily test, I've submitted a patch [1] which contains:
- Update www/libwpe to 1.14.1
- Update www/wpebackend-fdo to 1.14.2
- Update www/webkit2-gtk(3,4) to 2.38.6
- Add Mk/Uses/webkit.mk

www/webkit2-gtk3 contains FLAVORS for the 4.0 and 4.1 APIs.

[1] https://codeberg.org/olivierd/freebsd-ports-gnome/src/branch/patch/0001-www-webkit2-gtk-3-4-update-to-2.38.6.patch
Comment 8 Olivier Duchateau 2023-12-27 09:27:24 UTC
When I tried to build 2.40.x and 2.42.x releases (with clang 14 and 15 ), I got following errors

>In file included from /usr/ports/www/webkit2-gtk4/work/webkitgtk-2.40.2/Source/WebKit/WebKit2Prefix.h:75:
>In file included from /usr/include/c++/v1/algorithm:667:
>In file included from /usr/include/c++/v1/functional:499:
>In file included from /usr/include/c++/v1/__functional/bind.h:17:
>/usr/include/c++/v1/tuple:1596:5: error: attempt to use a deleted function
>    _VSTD::__invoke_constexpr(
>    ^
>/usr/include/c++/v1/__config:826:15: note: expanded from macro '_VSTD'
>#define _VSTD std
>              ^

> /usr/ports/www/webkit2-gtk4/work/webkitgtk-2.40.2/Source/WebKit/Platform/IPC/Decoder.h:132:20: error: call to implicitly-deleted copy constructor of 'std::optional<tuple<expected<pair<ObjectIdentifier<FileSystemHandleIdentifierType>, bool>, FileSystemStorageError>>>'
>            return t;
>                   ^

Full log is available [1].

[1] https://codeberg.org/olivierd/freebsd-ports-wip/src/branch/master/logs/clang15-webkit2-gtk4-2.40.2.log
Comment 9 Nuno Teixeira freebsd_committer freebsd_triage 2023-12-27 09:40:34 UTC
(In reply to Olivier Duchateau from comment #8)

Could you provide patch for 2.40.2 because patches doesn't apply clean when I switch for 2.28 to this one.

Ready to test on 14 and current, I'm curious about results :)
Comment 10 Charlie Li freebsd_committer freebsd_triage 2023-12-27 09:58:52 UTC
> Mk/Uses/webkit.mk
Why? If this is going to be flavourised, all three should be in the same port.
Comment 11 Nuno Teixeira freebsd_committer freebsd_triage 2023-12-27 10:04:38 UTC
(In reply to Nuno Teixeira from comment #9)
(...)
Fix typo:

- Applied 0001-www-webkit2-gtk-3-4-update-to-2.38.6.patch
- Update webkit gtk4 from 2.38.6 -> 2.40.2
- `make patch` fails
Comment 12 Nuno Teixeira freebsd_committer freebsd_triage 2023-12-29 09:24:30 UTC
https://github.com/shamazmazum/freebsd-ports/tree/master/www

Maybe worth to take a look at workaround to build 2.42.4.
It implies patch base compiler.

###
-#  if defined(__FreeBSD__)
-#    define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR
-#  endif
+//#  if defined(__FreeBSD__)
+//#    define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR
+//#  endif
###
Comment 13 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-11 13:45:46 UTC
I decided give a try on -gtk4 port and I found that some patches were taken from openbsd port and didn't been adusted to freebsd. We can see that by greping OPENBSD and see that most of those patches are doing nothing.

I adjusted patches when it seems to be logic to FREEBSD and I've got same result as Olivier:


(6 errors generated)
###
/usr/include/c++/v1/optional:841:35: note: candidate constructor template not viable: requires single argument '__v', but 2 arguments were provided
  841 |     _LIBCPP_CONSTEXPR_SINCE_CXX20 optional(const optional<_Up>& __v)
      |                                   ^        ~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/optional:849:44: note: candidate constructor template not viable: requires single argument '__v', but 2 arguments were provided
  849 |     _LIBCPP_CONSTEXPR_SINCE_CXX20 explicit optional(const optional<_Up>& __v)
      |                                            ^        ~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/optional:859:35: note: candidate constructor template not viable: requires single argument '__v', but 2 arguments were provided
  859 |     _LIBCPP_CONSTEXPR_SINCE_CXX20 optional(optional<_Up>&& __v)
###

I've googled about _LIBCPP_CONSTEXPR_SINCE_CXX20 and found that dim@ have solved some related problems on gcc, etc.

This weekend I will give a try at https://github.com/shamazmazum/freebsd-ports/tree/master/www and see how it goes.
Comment 14 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-11 13:49:21 UTC
(In reply to Nuno Teixeira from comment #13)
(...)

work done on 2.42.4
Comment 15 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-12 20:59:02 UTC
(In reply to Nuno Teixeira from comment #14)

Using shamaz port (-gtk3)

###
In file included from /wrkdirs/usr/ports/www/webkit2-gtk3/work/.build/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-51.cpp:1:
/wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/graphics/gstreamer/MediaSampleGStreamer.cpp:128:12: error: call to implicitly-deleted copy constructor of 'PlatformSample'
  128 |     return sample;
      |            ^~~~~~
/wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:66:7: note: copy constructor of 'PlatformSample' is implicitly deleted because field 'sample' has a deleted copy con
structor
   66 |     } sample;
      |       ^
/wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:65:83: note: copy constructor of '(unnamed union at /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source
/WebCore/platform/MediaSample.h:61:5)' is implicitly deleted because variant field 'byteRangeSample' has a non-trivial copy constructor
   65 |         std::pair<MTPluginByteSourceRef, std::reference_wrapper<const TrackInfo>> byteRangeSample;
      |                                                                                   ^
1 error generated.
###

Found old issue on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255528#c3 that share same error and a revert was done to fix it:

I'm working on patch-revert-11ccaf183fad that fails to get applied on new version.
Comment 16 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-13 16:46:43 UTC
(In reply to Nuno Teixeira from comment #15)
(...)

It ends in same error as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275914#c13
Comment 17 Olivier Duchateau 2024-01-14 10:53:54 UTC
Nuno, did you try with gcc?

WebKitGTK builds fine with this compiler. When I tested it was with gcc 12, but something is wrong with this compiler (I don't remember why). readelf(1) shows me libwebkitgtk-6.0.so (or libjavascriptcoregtk-6.0.so) was linked with wrong version of gcc (and crashes Epiphany). It also knows problem, there are several cases with same problem. Perhaps a test with higher version fixes this behaviour.

As WebKitGTK builds fine with gcc, I also tried to change the C++ standard library (USE_CXXSTD) but this change is not "propagated" when compiler is detected during configure stage. Our ports framework is not to blame! And there is nothing in CMakeFile.txt where we could change this library.
Comment 18 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-14 20:33:34 UTC
(In reply to Olivier Duchateau from comment #17)

> Nuno, did you try with gcc?

I will try to avoid it. It must be compiled with clang. Changing to gcc is not a solution unless we dealing with a special case.

My plan is to patch base/port clang to see how it goes with:

-#  if defined(__FreeBSD__)
-#    define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR
-#  endif
+//#  if defined(__FreeBSD__)
+//#    define _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR
+//#  endif

And then try to get help on why this is affecting build.

I've contacted author from https://github.com/shamazmazum/freebsd-ports/tree/master/www and he said to me that it was the only solution found to fix it.
Comment 19 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-24 16:26:16 UTC
(In reply to Nuno Teixeira from comment #18)

I've patched lang/llvm16 and used shamaz port (USES+=llvm:16), same build error with/without patch:

In file included from /wrkdirs/usr/ports/www/webkit2-gtk3/work/.build/WebCore/DerivedSources/unified-sources/UnifiedSource-3c72abbe-51.cpp:1:
/wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/graphics/gstreamer/MediaSampleGStreamer.cpp:128:12: error: call to implicitly-deleted copy constructor of 'PlatformSample'
    return sample;
           ^~~~~~
/wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:66:7: note: copy constructor of 'PlatformSample' is implicitly deleted because field 'sample' has a deleted copy con
structor
    } sample;
      ^
/wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source/WebCore/platform/MediaSample.h:65:83: note: copy constructor of '(unnamed union at /wrkdirs/usr/ports/www/webkit2-gtk3/work/webkitgtk-2.42.4/Source
/WebCore/platform/MediaSample.h:61:5)' is implicitly deleted because variant field 'byteRangeSample' has a non-trivial copy constructor
        std::pair<MTPluginByteSourceRef, std::reference_wrapper<const TrackInfo>> byteRangeSample;
                                                                                  ^
1 error generated.
Comment 20 Nuno Teixeira freebsd_committer freebsd_triage 2024-01-24 16:28:38 UTC
(In reply to Nuno Teixeira from comment #19)
> I've patched lang/llvm16 

** devel/llvm16

Any clues, any tips for further tests?
Comment 21 Charlie Li freebsd_committer freebsd_triage 2024-02-06 08:48:13 UTC
I just created review D43762 based from Olivier's 2.38.6 work, which we know builds without much issue. I consolidated all three combinations into one port, as the same exact codebase and build process cannot warrant more plus a Uses/.mk to boot. I'd like to commit 2.38 as a stopgap to allow consumers to adjust/correct their dependencies accordingly. We can keep this bug open to continue working on 2.42.
Comment 22 Nuno Teixeira freebsd_committer freebsd_triage 2024-02-06 09:28:21 UTC
(In reply to Charlie Li from comment #21)

Hello Charlie!

I did take a look at review and it seem very promising. I will test it very soon.
Thanks!
Comment 23 Charlie Li freebsd_committer freebsd_triage 2024-02-06 19:57:07 UTC
Testing with (mainly) epiphany, so far 2.38 "hangs" on launch as an effective zombie process, no window appears. truss(1)-ing both epiphany and WebKitWebDriver (what epiphany and other HTML-rendering consumers should spawn) shows something timing out and files not found, thence nothing until interrupted or killed.
Comment 24 Charlie Li freebsd_committer freebsd_triage 2024-02-07 02:47:56 UTC
(In reply to Charlie Li from comment #23)
Turns out there seems to be an indefinite wait condition in JavaScriptCore threading that is blocking further execution:

(lldb) bt
* thread #1, name = 'epiphany', stop reason = step over
  * frame #0: 0x000000082652a882 libthr.so.3`cond_wait_common [inlined] cond_wait_user(cvp=0x00003fcdfa8fd980, mp=0x00003fcdfae0c208, abstime=0x0000000000000000, cancel=1) at thr_cond.c:323:24
    frame #1: 0x000000082652a7af libthr.so.3`cond_wait_common(cond=<unavailable>, mutex=<unavailable>, abstime=0x0000000000000000, cancel=1) at thr_cond.c:378:11
    frame #2: 0x000000084098ac6d libjavascriptcoregtk-4.1.so.0`WTF::ThreadCondition::wait(WTF::Mutex&) at ThreadingPOSIX.cpp:603:18
    frame #3: 0x000000084098ad66 libjavascriptcoregtk-4.1.so.0`WTF::ThreadCondition::timedWait(WTF::Mutex&, WTF::WallTime) at ThreadingPOSIX.cpp:613:9
    frame #4: 0x00000008408b2cea libjavascriptcoregtk-4.1.so.0`WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) at ParkingLot.cpp:595:34
    frame #5: 0x000000083f607dc4 libjavascriptcoregtk-4.1.so.0`WTF::ParkingLot::ParkResult WTF::ParkingLot::parkConditionally<bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda'(), bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda0'()>(void const*, WTF::Lock const&, bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)::'lambda0'() const&, WTF::TimeWithDynamicClockType const&) at ParkingLot.h:82:16
    frame #6: 0x000000083f607d00 libjavascriptcoregtk-4.1.so.0`bool WTF::Condition::waitUntilUnchecked<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&) at Condition.h:192:22
    frame #7: 0x000000083f607bc5 libjavascriptcoregtk-4.1.so.0`WTF::Condition::waitUntil(WTF::Lock&, WTF::TimeWithDynamicClockType const&) at Condition.h:77:16
    frame #8: 0x0000000840974649 libjavascriptcoregtk-4.1.so.0`bool WTF::Condition::waitUntilUnchecked<WTF::Lock, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0>(WTF::Lock&, WTF::TimeWithDynamicClockType const&, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0 const&) at Condition.h:213:18
    frame #9: 0x00000008409745ed libjavascriptcoregtk-4.1.so.0`bool WTF::Condition::waitUntil<WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0>(WTF::Lock&, WTF::TimeWithDynamicClockType const&, WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&)::$_0 const&) at Condition.h:91:16
    frame #10: 0x0000000840974566 libjavascriptcoregtk-4.1.so.0`WTF::BinarySemaphore::waitUntil(WTF::TimeWithDynamicClockType const&) at BinarySemaphore.cpp:41:34
    frame #11: 0x0000000840898957 libjavascriptcoregtk-4.1.so.0`WTF::BinarySemaphore::wait() at BinarySemaphore.h:51:9
    frame #12: 0x0000000840978c11 libjavascriptcoregtk-4.1.so.0`WTF::WorkQueueBase::platformInitialize(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS) at WorkQueueGeneric.cpp:53:15
    frame #13: 0x000000084091f4b1 libjavascriptcoregtk-4.1.so.0`WTF::WorkQueueBase::WorkQueueBase(char const*, WTF::WorkQueueBase::Type, WTF::Thread::QOS) at WorkQueue.cpp:55:5
    frame #14: 0x00000008408ca439 libjavascriptcoregtk-4.1.so.0`WTF::WorkQueue::WorkQueue(char const*, WTF::Thread::QOS) at WorkQueue.h:104:11
    frame #15: 0x000000084091f57b libjavascriptcoregtk-4.1.so.0`WTF::WorkQueue::create(char const*, WTF::Thread::QOS) at WorkQueue.cpp:65:26
    frame #16: 0x0000000836ae973d libwebkit2gtk-4.1.so.0`WebKit::DeviceIdHashSaltStorage::DeviceIdHashSaltStorage(WTF::String const&) at DeviceIdHashSaltStorage.cpp:70:15
    frame #17: 0x0000000836ae93e9 libwebkit2gtk-4.1.so.0`WebKit::DeviceIdHashSaltStorage::create(WTF::String const&) at DeviceIdHashSaltStorage.cpp:49:50
    frame #18: 0x0000000836f65359 libwebkit2gtk-4.1.so.0`WebKit::WebsiteDataStore::WebsiteDataStore(WTF::Ref<WebKit::WebsiteDataStoreConfiguration, WTF::RawPtrTraits<WebKit::WebsiteDataStoreConfiguration>>&&, PAL::SessionID) at WebsiteDataStore.cpp:132:33
    frame #19: 0x0000000836f651e3 libwebkit2gtk-4.1.so.0`WebKit::WebsiteDataStore::create(WTF::Ref<WebKit::WebsiteDataStoreConfiguration, WTF::RawPtrTraits<WebKit::WebsiteDataStoreConfiguration>>&&, PAL::SessionID) at WebsiteDataStore.cpp:125:26
    frame #20: 0x0000000836dfc8dc libwebkit2gtk-4.1.so.0`webkitWebsiteDataManagerGetDataStore(_WebKitWebsiteDataManager*) at WebKitWebsiteDataManager.cpp:494:34
    frame #21: 0x0000000836dfe1d9 libwebkit2gtk-4.1.so.0`webkit_website_data_manager_set_persistent_credential_storage_enabled at WebKitWebsiteDataManager.cpp:887:5
    frame #22: 0x000000082170634f libephymain.so`___lldb_unnamed_symbol6069 + 127
    frame #23: 0x0000000824574ea0 libgobject-2.0.so.0`g_object_new_internal(class=0x00003fcdfa836400, params=0x0000000820542380, n_params=3) at gobject.c:2296:5
    frame #24: 0x00000008245749e2 libgobject-2.0.so.0`g_object_new_valist(object_type=70153904340096, first_property_name="application-id", var_args=0x0000000820542580) at gobject.c:2584:16
    frame #25: 0x0000000824573f2c libgobject-2.0.so.0`g_object_new(object_type=70153904340096, first_property_name="application-id") at gobject.c:2057:12
    frame #26: 0x00000008216d169d libephymain.so`_ephy_shell_create_instance + 205
    frame #27: 0x000000000022708c epiphany`main + 1340
    frame #28: 0x00000008279376c6 libc.so.7`__libc_start1(argc=1, argv=0x00000008205426c8, env=0x00000008205426d8, cleanup=<unavailable>, mainX=(epiphany`main)) at libc_start1.c:157:7
    frame #29: 0x00000000002262a0 epiphany`_start + 48
Comment 25 Charlie Li freebsd_committer freebsd_triage 2024-03-06 16:23:46 UTC
*** Bug 277526 has been marked as a duplicate of this bug. ***