dotnet在arm64中不能使用spatialite的问题定位

在项目中遇到的dotnet5在arm64 linux上部署失败问题，此仅作为记录。
1.dotnet5在arm64 linu部署失败问题
背景：在一个项目中，用dotnet5已经开发了用户权限管理的相关功能，经过讨论得知其实现的功能与另一个新的项目中需要的功能相差不大，但是在新的项目中开发时间较紧，经过大家讨论后想将原有项目已有功能中将用户权限管理独立出来作为一个服务端，缩短项目的开发周期。
 
在将服务端程序和dotnet5及相关的库部署到arm64 linux中时，服务端启动报错；报错信息如下：
Thread 58 ".NET ThreadPool" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7a187f01c0 (LWP 10430)]
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
dotnet/runtime#1 0x0000007a3c7134dc in sqlite3_busy_handler () from /usr/lib/aarch64-linux-gnu/libsqlite3.so.0
dotnet/runtime#2 0x0000007a9c1f3848 in sqlite3_busy_timeout () from /home//cellapi/runtimes/linux-arm64/native/libe_sqlite3.so
dotnet/runtime#3 0x0000007a5c2bda28 in init_spatialite_extension (pApi=, pzErrMsg=0x7a187eb630, db=0x7a20170b98)
at spatialite.c:53440
dotnet/runtime#4 sqlite3_modspatialite_init (db=0x7a20170b98, pzErrMsg=0x7a187eb630, pApi=) at spatialite.c:53637
dotnet/runtime#5 0x0000007a9c23e050 in sqlite3_load_extension ()
from /home//cellapi/runtimes/linux-arm64/native/libe_sqlite3.so
dotnet/runtime#6 0x0000007a9c23e25c in loadExt () from /home//cellapi/runtimes/linux-arm64/native/libe_sqlite3.so
dotnet/runtime#7 0x0000007a9c26fc8c in sqlite3VdbeExec () from /home//cellapi/runtimes/linux-arm64/native/libe_sqlite3.so
dotnet/runtime#8 0x0000007a9c271730 in sqlite3_step () from /home/***/cellapi/runtimes/linux-arm64/native/libe_sqlite3.so
dotnet/runtime#9 0x0000007f33a26b6c in ?? ()
dotnet/runtime#10 0x0000007fa7727ff0 in ?? () from /usr/share/dotnet/shared/Microsoft.NETCore.App/5.0.8/libcoreclr.so
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 
此报错信息显示服务启动挂死在名字为spatialite的第三方库中；
 
解决过程中的思路变化：
1）到spatialite库的官网去找不同版本的源码来编译arm64下的运行库，spatialite又需要依赖很多第三库，不影响此次功能的能屏蔽的第三库就将其屏蔽，不能屏蔽的只能根据报错信息继续寻找需要的源码并进行编译。经过1天2个晚上的试验均以失败而告终；
2）
a、米尔的系统没有软件包管理工具，手动编译效率较低，就在Jetson nano的开发板上做试验；Jetson nano的板和米尔的板用的是同一个平台的cpu，故能有参考意义；将dotnet5的服务端部署到nano上运行时也存在相同的报错信息，之后又用apt功能b、更换了几个spatialite的版本，也存在同样问题。
结合几天在网上查询到的信息，很少有人在arm64 linux使用dotnet5来部署应用；还有Windows发展在linux上的跨平台的历史也不久，可能测试也没有在所有平台下所有第三库得到充分的验证，有理由怀疑dotnet5对spatialite第三库支持存在问题；
b、在dotnet5的github提bug单，后经微软工程师的确认，不要在dotnet5上使用spatialite库。
c、修改方案，不使用spatialite库，自动实现依赖spatialite库的逻辑功能。