我有一个已编译的aarch64共享库（
my_custom.so我正在探索创建包含此库的 Linux aarch64 可执行文件的可能性。这将在服务器端启用相同的功能，作为 Android 设备的替代方案，利用常见的 aarch64 架构
遗憾的是，
my_custom.so我通过ldd、readelf等命令确认my_custom.so只依赖于libc.so、libc++_shared.so、liblog.so、libz.so。
但是，有一个错误表明库/lib64/libc.so有一个无效的ELF头：“/lib64/libc.so无效的elf头。”
使用cat命令后，确认/lib64/libc.so实际上是一个文本文件，实际的库文件是/lib64/libc.so.6。当我尝试创建从 /lib64/libc.so 到 /lib64/libc.so.6 的符号链接时，我遇到了错误：找不到版本 glibc。
我推测这种差异可能是由于 my_custom.so 是使用 NDK 编译的，该 NDK 使用的 libc 库与我当前的 Linux aarch64 环境中存在的库不同。因此，我试图在NDK的平台目录中找到相应的libc库。我从
NDK的平台目录复制了libc.so并在my_custom.so之前加载它，但遇到了**“未页面对齐”**错误。谷歌的研究表明，这可能是由于库与较大的页面大小不相符。由于当前系统的内存页面大小是不可修改的，我现在正在寻找 libc.so 的替代版本
从NDK中的/toolchains/llvm/prebuilt/复制libc.so后，我用ldd验证了它。我还从llvm目录复制了libc++_shared.so，也通过了ldd验证。
但是，当我运行整个程序时，它导致了核心转储......我想知道是否可以在 Linux aarch64 上运行 .so 库（由 NDK for Android aarch64 编译）。如果可以的话，我的做法正确吗？接下来我应该做什么？
我推测利用QEMU或Anbox等技术在Linux上运行Android虚拟机可能是一个可行的解决方案。但考虑到 my_custom.so 不依赖于任何 Android 系统组件，我发现虚拟机方法相对复杂且占用资源，导致潜在的资源浪费。
因为它是一个独立的低级计算库，不依赖于Android系统组件你的前提是错误的。它取决于 Android 加载器和 C 库。它不能在 GNU 系统上运行。
我想知道是否可以在 Linux aarch64 上运行 .so 库（由 NDK for Android aarch64 编译）。如果可以的话，我的做法正确吗？接下来我应该做什么？这并非“完全”不可能，但它很困难、复杂且脆弱。我已经简单地做到了，但是我使用的 aarch64 VM 很快就停止工作了，我放弃了这个想法。
对您来说最好的做法是重建 my_custom.so