Simon McVittie dixit:
[… detailed analysis …]
Thanks for looking into this.
I looked at libunwind for a bit, but it requires intricate
knowledge of debugging formats and everything.
>I've pushed a commit to gtk4 to disable the libsysprof-capture
>dependency and integration on architectures
On Sun, 24 Mar 2024 at 15:38:26 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
>
> >(Or of course porting libunwind to the remaining architectures would
> >be another obvious way that porters could address this.)
>
> Definitely. All three are valid possibilities.
>
> >Another possible
Simon McVittie dixit:
>(Or of course porting libunwind to the remaining architectures would
>be another obvious way that porters could address this.)
Definitely. All three are valid possibilities.
>Another possible way to attack this, particularly if libunwind is
>functionally necessary in
On Sun, 24 Mar 2024 at 00:36:11 +, Thorsten Glaser wrote:
> libunwind-dev is not available for at least alpha, hurd-any,
> loong64, m68k, sparc64, x32.
>
> sysprof is a not unimportant part in the GNOME dependency chain
> (IIRC seeing it for weston) and part of the t64 transition, so
> having
Source: sysprof
Version: 46~rc-1
Severity: important
Justification: unbuildable on some d-ports architectures
X-Debbugs-Cc: t...@mirbsd.de
libunwind-dev is not available for at least alpha, hurd-any,
loong64, m68k, sparc64, x32.
sysprof is a not unimportant part in the GNOME dependency chain
5 matches
Mail list logo
