[2025.5.0] 初期アイコンの生成がarm64の一部プロセッサだとうまく行かない？

[KisaragiEffective]

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.ts which 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 #16080 (reply in thread)

[KisaragiEffective]

related?: #15418, #12764

[KisaragiEffective]

今年は2025年なのでタイトルを修正

[AmaseCocoa]

(Sharkeyのv2025.4.2-rcですが) @napi-rs/canvasを使用するように変更したSharkeyでは、arm64環境でも正常にアイコンが生成できています。逆に、#15418 で使用されているcanvasを入れようとするとその時点でエラーが発生しまい、ビルドもできなくなります……（これに関しては単純にビルド時の依存関係の問題かもしれませんし(どこかで間違えているかもしれないけど依存関係入れた状態でもビルド時にエラーになっていたの忘れてました) Asahi + M2の環境が悪いのかもしれません）

[squidink7]

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 Brooooooklyn/canvas#1050

[KisaragiEffective]

In the meantime, probably better to downgrade and pin the napi-rs/canvas deendency to 0.1.68, according to bitfocus/companion@c437b02

[Mar0xy]

(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.

[AmaseCocoa]

(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.

[KisaragiEffective]

Raspi 4など一部のプロセッサしか影響を受けていないっぽいのでissueタイトルを変更

[Mar0xy]

@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 microsoft/vcpkg#31270

[AmaseCocoa]

@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-12

check 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.

[hikerus]

I mentioned the problem of not starting in #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]

@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#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.

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++