Linux动态库.so找不到符号表的排查指南

# 链接时找不到符号定义
/usr/bin/ld: main.o: in function `main':
main.cpp:(.text+0x2a): undefined reference to `foo()'
collect2: error: ld returned 1 exit status

# dlopen 时找不到符号
./app: symbol lookup error: ./libplugin.so: undefined symbol: _Z3foov

# 程序启动时找不到符号
./app: /usr/lib/libmylib.so: undefined symbol: bar

# 查看动态库中的所有符号
nm -D libmylib.so

# 常用选项组合：按符号名排序，显示动态符号
nm -CD libmylib.so | grep foo

# 输出含义：
# T / t  — 代码段中的符号（大写=全局，小写=局部）
# D / d  — 数据段中的符号
# U      — 未定义符号（Undefined，需要从其他库中解析）
# W      — 弱符号（Weak）
# A      — 绝对符号

$ nm -CD libmylib.so
                 w __gmon_start__
                 U __printf_chk@@GLIBC_2.17    # U = 这个符号在本库中未定义，需要外部提供
0000000000000690 T my_function                  # T = 这个符号在本库中定义，全局可见
0000000000000750 T my_class::do_work()          # C++ 方法（已 demangle）
0000000000002010 D my_global_var                # D = 全局变量定义

# 查看动态符号表
readelf -s libmylib.so

# 查看所有段头（定位符号表段是否存在）
readelf -S libmylib.so

# 查看动态段（NEEDED 条目 = 运行时依赖的库）
readelf -d libmylib.so

# 查看符号版本信息
readelf -V libmylib.so

# 查看重定位条目（哪些符号需要被重定位）
readelf -r libmylib.so

$ readelf -s libmylib.so

Symbol table '.dynsym' contains 15 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __printf_chk@GLIBC_2.17
     2: 0000000000000690   120 FUNC    GLOBAL DEFAULT   11 my_function
     3: 0000000000000750    56 FUNC    GLOBAL DEFAULT   11 _ZN8my_class7do_workEv
                                                                     ↑ 这是 C++ mangled name

$ readelf -d libmylib.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

# 查看符号表
objdump -T libmylib.so

# 查看所有段头
objdump -x libmylib.so | head -50

# 反汇编特定函数（需要非 strip 的库）
objdump -d libmylib.so | grep -A 20 '<my_function>'

# 查看程序运行时依赖的所有 .so
ldd ./myapp

# 查看某个 .so 的依赖
ldd libmylib.so

# 典型输出
$ ldd ./myapp
    linux-vdso.so.1 (0x00007ffc12bfe000)
    libmylib.so => /usr/local/lib/libmylib.so (0x00007f8a1c200000)  # ✓ 找到了
    libfoo.so => not found                                            # ✗ 找不到！
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8a1be00000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f8a1c600000)

# 查看符号绑定过程（最常用）
LD_DEBUG=symbols ./myapp

# 查看库文件查找过程
LD_DEBUG=libs ./myapp

# 查看重定位过程
LD_DEBUG=reloc ./myapp

# 查看所有调试信息
LD_DEBUG=all ./myapp

# 输出到文件而非 stderr
LD_DEBUG=symbols LD_DEBUG_OUTPUT=/tmp/ld_debug ./myapp

$ LD_DEBUG=symbols ./myapp 2>&1 | grep foo
     10567: symbol=foo;  lookup in file=./myapp [0]
     10567: symbol=foo;  lookup in file=libmylib.so [0]
     10567: symbol=foo;  lookup in file=libc.so.6 [0]
     10567: symbol=foo;  lookup in file=ld-linux-x86-64.so.2 [0]
     10567: symbol=foo;  error: symbol not found          # ← 所有库都找遍了，没找到

# 还原 mangled 名称
$ echo '_ZN8my_class7do_workEv' | c++filt
my_class::do_work()

# 结合 nm 使用
nm libmylib.so | c++filt

# 结合 grep 使用
nm -D libmylib.so | c++filt | grep 'my_class::do_work'

# 如果是 mangled name（以 _Z 开头），先 demangle
$ c++filt _Z3foov
foo()

# 在所有相关库中搜索该符号
nm -CD libprovider1.so | grep foo
nm -CD libprovider2.so | grep foo

# 或者用 readelf
readelf -s libprovider1.so | grep foo
readelf -s libprovider2.so | grep foo

# 系统范围搜索（需要 locate 或 find）
# 方法 1：用 locate 快速定位
locate libfoo.so | xargs -I{} sh -c 'nm -CD {} 2>/dev/null | grep -l foo && echo {}'

# 方法 2：在已知目录下搜索
for lib in /usr/lib/*.so /usr/local/lib/*.so; do
    nm -CD "$lib" 2>/dev/null | grep -q 'T foo' && echo "$lib"
done

# 检查依赖链
ldd ./myapp | grep libprovider

# 检查 RPATH/RUNPATH
readelf -d ./myapp | grep -E 'RPATH|RUNPATH'

# 检查 LD_LIBRARY_PATH
echo $LD_LIBRARY_PATH

# 检查符号是否被导出
nm -CD libprovider.so | grep foo
# 如果没有 T/D 类型的条目，说明符号未导出

# 检查符号是否被 strip 掉
readelf -S libprovider.so | grep -E 'symtab|dynsym'
# 如果 .symtab 不存在但 .dynsym 存在，说明被 strip 了（正常）
# 如果 .dynsym 也没有，说明编译时就没有导出

# 查看符号版本要求
readelf -V libprovider.so
objdump -T libprovider.so | grep foo

// libcalc.c — 纯 C 库
int add(int a, int b) {
    return a + b;
}

// main.cpp — C++ 程序
#include <cstdio>
// ❌ 缺少 extern "C" 声明
int add(int a, int b);
int main() {
    printf("%d\n", add(1, 2));
    return 0;
}

# 编译 C 库
gcc -shared -fPIC -o libcalc.so libcalc.c

# 编译 C++ 程序
g++ main.cpp -L. -lcalc -o main

# 运行报错
$ ./main
./main: symbol lookup error: ./main: undefined symbol: _Z3addii

# 看库中导出的符号名
$ nm -D libcalc.so | grep add
0000000000000690 T add                # C 库导出的是 "add"

# 看程序需要的符号名
$ nm main | grep add
                 U _Z3addii           # C++ 程序找的是 "_Z3addii"（mangled name）

# demangle 确认
$ c++filt _Z3addii
add(int, int)

// main.cpp — 正确写法
#include <cstdio>
extern "C" {           // ✓ 告诉编译器按 C 的方式查找符号
    int add(int a, int b);
}
int main() {
    printf("%d\n", add(1, 2));
    return 0;
}

// libcalc.h — 兼容 C 和 C++ 的头文件
#ifdef __cplusplus
extern "C" {
#endif
int add(int a, int b);
#ifdef __cplusplus
}
#endif

// libfoo.c
int foo() { return 42; }

# ❌ 编译 .o 时没有 -fPIC
gcc -c libfoo.c
gcc -shared -o libfoo.so libfoo.o

# 可能出现的警告或错误
/usr/bin/ld: libfoo.o: relocation R_X86_64_PC32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC

# 检查 .o 文件的重定位类型
readelf -r libfoo.o | head

# 如果看到 R_X86_64_PC32 而非 R_X86_64_PLT32 / R_X86_64_GOTPCREL，
# 说明编译时没有使用 -fPIC

# ✓ 编译 .o 时加 -fPIC
gcc -fPIC -c libfoo.c
gcc -shared -o libfoo.so libfoo.o

# 或者一步完成
gcc -shared -fPIC -o libfoo.so libfoo.c

// main.cpp
#include "liba.h"    // liba 中的函数依赖 libb
int main() {
    func_from_a();   // 该函数内部调用了 func_from_b()
    return 0;
}

# ❌ 错误的链接顺序：liba 在 libb 之前
g++ main.cpp -la -lb -o main
# 报错：undefined reference to `func_from_b()'

# ✓ 正确的链接顺序：被依赖的库放后面
g++ main.cpp -la -lb -o main    # 如果 a 依赖 b，应该把 b 放在 a 后面

# 确认库之间的依赖关系
nm -D liba.so | grep ' U '      # 查看 liba 的未定义符号
nm -D libb.so | grep ' T '      # 查看 libb 定义了哪些符号

# 交叉对比
nm -D liba.so | awk '$1=="U"{print $2}' | while read sym; do
    nm -D libb.so | grep -q " T $sym" && echo "libb provides: $sym"
done

# 编译时链接了新版本的 libfoo（有 foo@@VER_2.0）
g++ main.cpp -lfoo -o main

# 运行时加载了旧版本的 libfoo（只有 foo@@VER_1.0）
$ LD_LIBRARY_PATH=/old/lib ./main
./main: /old/lib/libfoo.so: version `FOO_2.0' not found

# 查看程序需要的符号版本
$ objdump -T main | grep FOO
0000000000000000      DF *UND*  0000000000000000  FOO_2.0  foo

# 查看库提供的符号版本
$ objdump -T /old/lib/libfoo.so | grep FOO
0000000000000690 g    DF .text  000000000000001a  FOO_1.0  foo
                                                    ↑ 只有 1.0

$ objdump -T /new/lib/libfoo.so | grep FOO
0000000000000690 g    DF .text  000000000000001a  FOO_2.0  foo
                                                    ↑ 有 2.0

# 查看库的版本定义
$ readelf -V /old/lib/libfoo.so
Version definition section '.gnu.version_d' contains 2 entries:
  Addr: 0x00000000000002d8  Offset: 0x0002d8  Link: 3 (.dynstr)
    00000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libfoo.so
    0x001c9880: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: FOO_1.0

# 方法 1：确保运行时使用正确版本的库
LD_LIBRARY_PATH=/new/lib ./main

# 方法 2：使用 LD_PRELOAD 强制加载特定版本
LD_PRELOAD=/new/lib/libfoo.so ./main

# 方法 3：设置 RPATH 使可执行文件记住库路径
g++ -Wl,-rpath,/new/lib main.cpp -lfoo -o main

// main.cpp — 主程序
#include <dlfcn.h>
#include <cstdio>
void host_function() {       // 主程序中定义的函数
    printf("host_function called\n");
}
int main() {
    // ❌ 只用了 RTLD_LAZY，没有 RTLD_GLOBAL
    void* handle = dlopen("./libplugin.so", RTLD_LAZY);
    if (!handle) {
        fprintf(stderr, "%s\n", dlerror());
        return 1;
    }
    typedef void (*plugin_init_t)();
    auto plugin_init = (plugin_init_t)dlsym(handle, "plugin_init");
    plugin_init();
    dlclose(handle);
    return 0;
}

// plugin.cpp — 插件
#include <cstdio>
extern void host_function();  // 引用主程序的符号
extern "C" void plugin_init() {
    host_function();          // ← 运行时报 undefined symbol
}

# 编译
g++ -shared -fPIC -o libplugin.so plugin.cpp
g++ -rdynamic -o main main.cpp -ldl    # -rdynamic 让主程序导出符号

# 运行
$ ./main
./libplugin.so: undefined symbol: host_function

# 确认主程序确实导出了该符号
$ nm -D main | grep host_function
0000000000001179 T host_function       # ✓ 主程序导出了

# 确认插件需要该符号
$ nm -D libplugin.so | grep host_function
                 U host_function       # U = 未定义，需要外部提供

# 问题在于 dlopen 的默认作用域

// 方法 1：使用 RTLD_LAZY | RTLD_GLOBAL（推荐）
void* handle = dlopen("./libplugin.so", RTLD_LAZY | RTLD_GLOBAL);

// 方法 2：主程序编译时加 -rdynamic（已加），并确保 dlopen 之前符号可用

// registry.h — 自动注册模式
#include <map>
#include <string>
struct Registry {
    static std::map<std::string, int>& entries() {
        static std::map<std::string, int> m;
        return m;
    }
};
#define REGISTER(name, val) \
    static bool _reg_##name = (Registry::entries()[#name] = val, true)

// foo_plugin.cpp
#include "registry.h"
REGISTER(foo, 1)    // 全局静态变量的构造函数会执行注册

// bar_plugin.cpp
#include "registry.h"
REGISTER(bar, 2)

# 编译为静态库
g++ -c foo_plugin.cpp -o foo_plugin.o
g++ -c bar_plugin.cpp -o bar_plugin.o
ar rcs libplugins.a foo_plugin.o bar_plugin.o

# 链接到动态库
g++ -shared -fPIC -o libmyapp.so -L. -lplugins

# 运行时发现注册表中为空！

# 检查动态库中是否有注册相关的符号
$ nm -D libmyapp.so | grep _reg_
# 空输出！符号被丢弃了

# 检查静态库中确实有这些符号
$ nm libplugins.a | grep _reg_
foo_plugin.o:
0000000000000000 d _reg_foo

bar_plugin.o:
0000000000000000 d _reg_bar

# 方法 1：使用 --whole-archive 强制包含所有符号
g++ -shared -fPIC -o libmyapp.so \
    -Wl,--whole-archive -L. -lplugins -Wl,--no-whole-archive
# 方法 2：在代码中显式引用（不推荐，但简单）
# 在某个会被引用的函数中添加：
extern bool _reg_foo;
extern bool _reg_bar;
void force_reference() {
    (void)_reg_foo;
    (void)_reg_bar;
}
# 方法 3：直接用 .o 文件而非静态库
g++ -shared -fPIC -o libmyapp.so foo_plugin.o bar_plugin.o

# /usr/include/mylib.h — 新版本（v2.0），声明了 new_api()
# /usr/lib/libmylib.so — 旧版本（v1.0），没有 new_api()
# /usr/local/lib/libmylib.so — 新版本（v2.0），有 new_api()

# 编译时用了新头文件
g++ main.cpp -I/usr/include -lmylib -o main

# 链接时找到了旧版库
$ ldd main | grep mylib
libmylib.so => /usr/lib/libmylib.so    # ← 旧版！

# 运行报错
$ ./main
./main: symbol lookup error: ./main: undefined symbol: new_api

# 1. 确认链接了哪个库
ldd main | grep mylib

# 2. 确认库中是否有该符号
nm -CD /usr/lib/libmylib.so | grep new_api       # 旧版：没有
nm -CD /usr/local/lib/libmylib.so | grep new_api  # 新版：有

# 3. 确认头文件版本
grep new_api /usr/include/mylib.h       # 有声明

# 方法 1：设置 LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

# 方法 2：编译时设置 RPATH
g++ main.cpp -I/usr/local/include -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lmylib -o main

# 方法 3：使用 pkg-config 确保一致性
g++ main.cpp $(pkg-config --cflags --libs mylib) -o main

# 在 x86 开发机上编译 ARM64 动态库
aarch64-linux-gnu-g++ -shared -fPIC -o libfoo.so foo.cpp

# ❌ 在 x86 机器上直接用 ldd 检查 ARM 库
$ ldd libfoo.so
    not a dynamic executable

# ❌ 在 x86 机器上直接运行 ARM 程序
$ ./myapp
bash: ./myapp: cannot execute binary file: Exec format Error

# ❌ 用本地 nm 查看（虽然能看符号，但容易忽略架构差异）
$ nm -D libfoo.so
# 能输出符号，但无法验证运行时依赖链是否完整

# ✓ 方法 1：使用交叉编译工具链自带的工具
aarch64-linux-gnu-nm -D libfoo.so
aarch64-linux-gnu-readelf -s libfoo.so
aarch64-linux-gnu-readelf -d libfoo.so | grep NEEDED
aarch64-linux-gnu-objdump -T libfoo.so

# ✓ 方法 2：直接在 ARM64 目标机器上排查（最可靠）
# 拷贝到目标机后：
ssh arm-device
nm -D libfoo.so
readelf -d libfoo.so | grep NEEDED
ldd ./myapp        # 在目标机上 ldd 才有意义

# 交叉编译时，未正确指定 sysroot
aarch64-linux-gnu-g++ main.cpp -lfoo -o myapp

# 编译可能成功（因为找到了 x86 的 libfoo.so），但生成的二进制是混合架构
# 部署到 ARM 机器后：
$ ./myapp
./myapp: error while loading shared libraries: libfoo.so: wrong ELF class: ELFCLASS64
# 或者
./myapp: /usr/lib/libfoo.so: cannot open shared object file: Exec format error

# 1. 检查 ELF 文件的架构
$ readelf -h libfoo.so | grep -E 'Machine|Class'
  Class:                             ELF64
  Machine:                           AArch64           # ✓ ARM64

$ readelf -h /usr/lib/libfoo.so | grep -E 'Machine|Class'
  Class:                             ELF64
  Machine:                           Advanced Micro Devices X86-64  # ✗ x86_64！链接了错误的库

# 2. 检查可执行文件依赖的所有库的架构
$ for lib in $(ldd myapp | awk '{print $3}' | grep -v '^$'); do
    echo "=== $lib ==="
    readelf -h "$lib" 2>/dev/null | grep Machine
done

# 3. 检查编译时链接了哪些路径
$ aarch64-linux-gnu-g++ main.cpp -lfoo -o myapp -v 2>&1 | grep 'LIBRARY_PATH'
# 如果输出包含 /usr/lib 而非 /usr/aarch64-linux-gnu/lib，说明链接了 x86 系统库

# ✓ 方法 1：使用 --sysroot 指定目标架构的根文件系统
aarch64-linux-gnu-g++ main.cpp -lfoo -o myapp \
    --sysroot=/usr/aarch64-linux-gnu

# ✓ 方法 2：显式指定库搜索路径
aarch64-linux-gnu-g++ main.cpp -lfoo -o myapp \
    -L/usr/aarch64-linux-gnu/lib

# ✓ 方法 3：使用 CMake 交叉编译工具链文件（推荐）

# toolchain-aarch64.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)
set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)
# 关键：指定 sysroot 和搜索路径
set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

cmake -DCMAKE_TOOLCHAIN_FILE=toolchain-aarch64.cmake ..
make

# 在 x86 开发机上用较新的交叉编译工具链编译
aarch64-linux-gnu-g++ -shared -fPIC -o libmyapp.so myapp.cpp

# 部署到 ARM 目标机（可能是较老的嵌入式系统）
$ ./myapp
./myapp: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found
./myapp: /lib/libc.so.6: version `GLIBC_2.33' not found

# 1. 在 x86 开发机上检查交叉编译的库需要哪些符号版本
$ aarch64-linux-gnu-readelf -V libmyapp.so | grep -E 'GLIBC|GLIBCXX'
Version needs section '.gnu.version_r' contains 3 entries:
  0x00008000: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: GLIBC_2.33
  0x00008010: Rev: 1  Flags: none  Index: 3  Cnt: 1  Name: GLIBCXX_3.4.29

# 2. 在 ARM 目标机上检查可用的符号版本
$ strings /usr/lib/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.9
...
GLIBCXX_3.4.21      # ← 最高只到 3.4.21，远低于需要的 3.4.29

$ strings /lib/libc.so.6 | grep GLIBC
GLIBC_2.17
...
GLIBC_2.31          # ← 最高只到 2.31，低于需要的 2.33

# 3. 列出库的所有未定义符号及其版本要求
$ aarch64-linux-gnu-objdump -T libmyapp.so | grep '*UND*'
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.33  memcpy
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.29  _ZNSt7__cxx1112basic_string...

# 方法 1：使用与目标系统匹配的交叉编译工具链版本
# 如果目标机是 Ubuntu 20.04（glibc 2.31），就用对应版本的 sysroot
aarch64-linux-gnu-g++ -shared -fPIC -o libmyapp.so myapp.cpp \
    --sysroot=/path/to/ubuntu20.04-aarch64-sysroot

# 方法 2：将交叉编译工具链的运行时库一起部署到目标机
# 拷贝交叉编译器的 libstdc++ 和 libgcc
scp /usr/aarch64-linux-gnu/lib/libstdc++.so.6.0.29 arm-device:/opt/lib/
scp /usr/aarch64-linux-gnu/lib/libgcc_s.so.1 arm-device:/opt/lib/
# 在目标机上设置 LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/opt/lib:$LD_LIBRARY_PATH

# 方法 3：静态链接 C/C++ 运行时（简单但增加体积）
aarch64-linux-gnu-g++ -shared -fPIC -o libmyapp.so myapp.cpp \
    -static-libgcc -static-libstdc++

# 方法 4：使用 Docker 构建可控的交叉编译环境（推荐，可复现）

# Dockerfile.cross-build
FROM ubuntu:20.04

RUN apt-get update && apt-get install -y \
    gcc-aarch64-linux-gnu \
    g++-aarch64-linux-gnu \
    libc6-dev-arm64-cross \
    libstdc++-8-dev-arm64-cross

# 此环境中的 glibc/libstdc++ 版本与 Ubuntu 20.04 一致
# 确保编译出的 .so 在目标机上兼容

# 将 libfoo.so 部署到 ARM 目标机的 /opt/myapp/lib/
$ ./myapp
./myapp: error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory

# 但库确实存在
$ ls -la /opt/myapp/lib/libfoo.so
-rwxr-xr-x 1 root root 123456 Apr 24 10:00 /opt/myapp/lib/libfoo.so

# 1. 确认动态链接器搜索了哪些路径
$ LD_DEBUG=libs ./myapp 2>&1 | head -20
     1234: find library=libfoo.so [0]; searching
     1234:  search cache=/etc/ld.so.cache
     1234:  search path=/usr/lib:/lib        # ← 默认路径，没有 /opt/myapp/lib

# 2. 检查 ld.so.conf 配置
$ cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

$ ls /etc/ld.so.conf.d/
libc.conf  # 只包含 /usr/lib

# 3. 检查可执行文件的 RPATH
$ readelf -d myapp | grep -E 'RPATH|RUNPATH'
# 空输出 — 没有设置 RPATH

# 方法 1：临时方案 — 设置 LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/opt/myapp/lib:$LD_LIBRARY_PATH
./myapp

# 方法 2：永久方案 — 添加到 ld.so.conf
echo "/opt/myapp/lib" > /etc/ld.so.conf.d/myapp.conf
ldconfig                          # 刷新缓存
ldconfig -p | grep libfoo         # 验证缓存中已有该库

# 方法 3：编译时嵌入 RPATH（推荐）
aarch64-linux-gnu-g++ main.cpp -lfoo -o myapp \
    -Wl,-rpath,/opt/myapp/lib \
    -L/opt/myapp/lib

# 方法 4：使用 $ORIGIN 实现相对路径 RPATH（部署更灵活）
aarch64-linux-gnu-g++ main.cpp -lfoo -o myapp \
    -Wl,-rpath,'$ORIGIN/lib'      # $ORIGIN = 可执行文件所在目录
# 这样只要 libfoo.so 在 myapp 同级的 lib/ 目录下就能找到

# 目标机是 ARM32，但用 ARM64 工具链编译
aarch64-linux-gnu-g++ -shared -fPIC -o libfoo.so foo.cpp

# 部署到 ARM32 目标机
$ ./myapp
./myapp: error while loading shared libraries: ./libfoo.so: wrong ELF class: ELFCLASS64

# 反过来：目标机是 ARM64，但用 ARM32 工具链编译
arm-linux-gnueabihf-g++ -shared -fPIC -o libfoo.so foo.cpp

$ ./myapp
./myapp: error while loading shared libraries: ./libfoo.so: wrong ELF class: ELFCLASS32

# 确认 .so 的架构
$ readelf -h libfoo.so | grep -E 'Class|Machine'
  Class:                             ELF64        # 64 位
  Machine:                           AArch64      # ARM64

# 确认目标机的架构
$ uname -m
armv7l          # ARM32

# 或者
$ dpkg --print-architecture
armhf           # ARM32 硬浮点

# ARM32 (armhf) 交叉编译
arm-linux-gnueabihf-g++ -shared -fPIC -o libfoo.so foo.cpp

# ARM64 (aarch64) 交叉编译
aarch64-linux-gnu-g++ -shared -fPIC -o libfoo.so foo.cpp

# 始终在部署前验证架构一致性
readelf -h libfoo.so | grep Machine
# Machine:                           ARM            → ARM32
# Machine:                           AArch64        → ARM64

// 1. C/C++ 兼容的头文件写法
#ifdef __cplusplus
extern "C" {
#endif
void c_api_function(void);
#ifdef __cplusplus
}
#endif
// 2. 导出宏（控制符号可见性）
#ifdef MYLIB_EXPORTS
    #define MYLIB_API __attribute__((visibility("default")))
#else
    #define MYLIB_API
#endif
MYLIB_API void exported_function(void);
// 3. 隐藏不需要导出的符号
__attribute__((visibility("hidden"))) void internal_function(void);

# 设置 -fPIC
set(CMAKE_POSITION_INDEPENDENT_CODE ON)

# 设置 RPATH
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
set(CMAKE_BUILD_RPATH "${CMAKE_BINARY_DIR}")

# 链接时检查未定义符号
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined")

# 使用 --whole-archive
target_link_libraries(myapp
    PRIVATE
    "-Wl,--whole-archive"
    plugins
    "-Wl,--no-whole-archive"
)