misskey-dev
[2025.5.0] 初期アイコンの生成がarm64の一部プロセッサだとうまく行かない？
Just found a fix! After tracing through all the imports I landed on @napi-rs/canvas as the module that causes this error. I'm running Misskey on a Raspberry Pi (arm64) which that library seemingly does not work on. I had to comment out the import in
packages/backend/src/misc/gen-identicon.tswhich breaks identicon generation, but if you have that disabled on your instance then it allows the rest of the server to run.
Originally posted by @squidink7 in https://github.com/misskey-dev/misskey/discussions/16080#discussioncomment-13262437
(Sharkeyのv2025.4.2-rcですが) @napi-rs/canvasを使用するように変更したSharkeyでは、arm64環境でも正常にアイコンが生成できています。逆に、#15418 で使用されているcanvasを入れようとするとその時点でエラーが発生しまい、ビルドもできなくなります……（~~これに関しては単純にビルド時の依存関係の問題かもしれませんし~~(どこかで間違えているかもしれないけど依存関係入れた状態でもビルド時にエラーになっていたの忘れてました) Asahi + M2の環境が悪いのかもしれません）
The particular error generated is Illegal Instruction, which implies @napi-rs/canvas tried to execute an instruction the CPU doesn't support. I would suspect this may mean it works on some arm64 devices (like the M2 Mac) but not others (like the RPi4). Though really this is out of scope for Misskey and should be resolved upstream https://github.com/Brooooooklyn/canvas/issues/1050
In the meantime, probably better to downgrade and pin the napi-rs/canvas deendency to 0.1.68, according to https://github.com/bitfocus/companion/commit/c437b02bac8a85c3d9bbb864ae2fa18e9df89947
(Sharkeyのv2025.4.2-rcですが)
@napi-rs/canvasを使用するように変更したSharkeyでは、arm64環境でも正常にアイコンが生成できています。逆に、#15418 で使用されているcanvasを入れようとするとその時点でエラーが発生しまい、ビルドもできなくなります……（~これに関しては単純にビルド時の依存関係の問題かもしれませんし~(どこかで間違えているかもしれないけど依存関係入れた状態でもビルド時にエラーになっていたの忘れてました) Asahi + M2の環境が悪いのかもしれません）
This most definitely is due to missing dependencies as you need pixman, cairo and pango installed on your system if you don't use the docker.
see:
https://activitypub.software/TransFem-org/Sharkey/-/blob/develop/Dockerfile?ref_type=heads#L7
https://activitypub.software/TransFem-org/Sharkey/-/issues/1021#note_12317
If it still fails to build then something else might be wrong as it builds fine on our arm64 runners as well as for most people running it without docker.
(Sharkeyのv2025.4.2-rcですが)
@napi-rs/canvasを使用するように変更したSharkeyでは、arm64環境でも正常にアイコンが生成できています。逆に、#15418 で使用されているcanvasを入れようとするとその時点でエラーが発生しまい、ビルドもできなくなります……（~これに関しては単純にビルド時の依存関係の問題かもしれませんし~(どこかで間違えているかもしれないけど依存関係入れた状態でもビルド時にエラーになっていたの忘れてました) Asahi + M2の環境が悪いのかもしれません）This most definitely is due to missing dependencies as you need pixman, cairo and pango installed on your system if you don't use the docker.
see:
https://activitypub.software/TransFem-org/Sharkey/-/blob/develop/Dockerfile?ref_type=heads#L7
https://activitypub.software/TransFem-org/Sharkey/-/issues/1021#note_12317
If it still fails to build then something else might be wrong as it builds fine on our arm64 runners as well as for most people running it without docker.
I checked the dependency itself with dnf and it was included. but, when building, I get an error that uint8_t and state are not declared within the scope, so I'm wondering if something is wrong. I'll look into this a bit more (it's working fine now so there's not much need to look into it, but I'm curious).
I have almost no knowledge of C so I think I must be doing something wrong.
@AmaseCocoa what g++/gcc version is on the pi? I assume 13.2 as that is latest on noble/lts. cause afaik there were issues with specific gcc 13 versions where uint8_t kinda broke i know it works on 13.3 and 12.x so you can try getting gcc-12 and then building it (make sure that it also uses version 12 when building and not version 13 by setting either the env variables to it or removing gcc 13)
check out https://github.com/microsoft/vcpkg/issues/31270
@AmaseCocoa what g++/gcc version is on the pi? I assume 13.2 as that is latest on noble/lts. cause afaik there were issues with specific gcc 13 versions where kinda broke i know it works on 13.3 and 12.x so you can try getting and then building it (make sure that it also uses version 12 when building and not version 13 by setting either the env variables to it or removing gcc 13)
uint8_t``gcc-12check out microsoft/vcpkg#31270
Thanks.
It looks like Fedora 42 ships with gcc and g++ 15.1.1.
I tried it, but Fedora 42 may not distribute gcc-13 or gcc-12, so I decided to compile gcc myself and give it a try.
I mentioned the problem of not starting in https://github.com/misskey-dev/misskey/discussions/16080 on a Raspi4 under Ubuntu 24.04.2.
This installation has
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
g++ (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
@AmaseCocoa what g++/gcc version is on the pi? I assume 13.2 as that is latest on noble/lts. cause afaik there were issues with specific gcc 13 versions where kinda broke i know it works on 13.3 and 12.x so you can try getting and then building it (make sure that it also uses version 12 when building and not version 13 by setting either the env variables to it or removing gcc 13)
uint8_tgcc-12 `` check out microsoft/vcpkg#31270Thanks.
It looks like Fedora 42 ships with gcc and g++ 15.1.1.
I tried it, but Fedora 42 may not distribute gcc-13 or gcc-12, so I decided to compile gcc myself and give it a try.
OK, I solved the problem by compiling gcc/g++ 13.3.0 and changing CC and CXX environment variables to the path to compiled gcc/g++
This error seems to be resolved as @napi-rs/canvas was upgraded in Misskey 2025.8.0.
The official misskey docker image worked on my Raspberry Pi 4 (2025.5.0 - 2025.7.0 didn't work on this environment).
The original issue was already closed: https://github.com/Brooooooklyn/canvas/issues/1036
@napi-rs/canvasがMisskey 2025.8.0でアップデートされたので、この問題は解決されていそうでした。
自分のRaspi 4でmisskey/misskeyのdocker imageが問題なく動きました(2025.5.0 - 2025.7.0では動いていませんでした)。
元のissueも解決しています。
Probably fixed in #16201, according to above report. Thank you for reporting and verifying!