楼主:
cole945 (跶跶..)
2018-08-25 19:11:06→ lovejomi: 不过uniqueptr真的不能使用default deleter吗 08/25 00:28
如果以 linux 的 abi 设计来说, 没有跨 library 不能使用的道理,
大部份的情况 dynamic/static linking 不会有差别, 对使用者无感
但不知道你有没有什么使用上的特殊需求, 为什么会特别在意能不能在
shared object 回传 uniqe_ptr?
如果你担心的是因为 lib 不合, 所以 new/delete 会有问题,
那连 .so 能不能 create 一个 uniqe_ptr 给 main 用本身都是个问题了,
还轮不到 delete 能不能删到同一个 heap 的东西
正常 dynamic link 的 elf 会有像下面这些资讯
这里分别指定 new 和 delete 要使用 3.4 版 GLIBCXX
0000000000202f98 0000000500000007 R_X86_64_JUMP_SLOT 0000000000000000
[email protected]_3.4 + 0
0000000000202fa0 0000000600000007 R_X86_64_JUMP_SLOT 0000000000000000
[email protected]_3.4 + 0
0x0050: Version: 1 File: libstdc++.so.6 Cnt: 3
0x0060: Name: CXXABI_1.3.9 Flags: none Version: 5
0x0070: Name: CXXABI_1.3 Flags: none Version: 3
0x0080: Name: GLIBCXX_3.4 Flags: none Version: 2
推 lovejomi: 我遇到 a.exe 使用vector<.so type> 然后.so 里面也使 08/25 00:32
→ lovejomi: 用这种vector<type>..两者用不同版本编，link的时候出现 08/25 00:32
→ lovejomi: warning possible ODR violation....是不是表示a.exe最 08/25 00:32
→ lovejomi: 终可能是link到.so的vector实作，也可能是自己的vector 08/25 00:33
→ lovejomi: 实作？决定权在linker? 08/25 00:33
我没这样用过你的情况, 不过键盘推理应该是这样.....
先讲结论, linker 应该不会发现有问题,
但 loader 会因为无法戴入其中一个 libstdc++.so 就终止执行
假设 a.exe 和 foo.so 分别对 A 版与 B 版的 libstdc++编译
因为 stl 是 template source 展开, 所以不会版号资讯,
而 a.exe 与 foo.so 会自各有一份 vector 的实作 (例如 vector<int>::push_back)
(依实作) 各自都会是 weak symbol
当 link a.exe 与 foo.so 时 (若非使用 dlopen 的情况)
因为 push_back 已经存在, 也都为 weak symbol,
所以 linker 不会认为有什么问题
依 System V ABI, a.exe 可以直接解为 A 版的实作,
但 foo.so 需经过 PLT 表, 等 loader 解
执行 a.exe, loader 戴入 foo.so 时, 因为 a.exe 存在symbol,
依 System V ABI, foo.so 应使用 a.exe 的 A 版本
如果故事只到这里应该就炸掉了
不过因为 a.exe 和 foo.so 各自会有额外的 shared object dependency,
要求指定的 libstdc++.so, 依当时的执行环境, 正常来说只会存在 A 或 B 版,
不会并存, 所以 loader 会因为无法戴入其中一个版本而终止执行
如果你没有特殊需求, 通常 dynamic link 省事一点, 至少不用每次 relink.
有些特殊 API 不适合 static link, 强制 static 也要搭合相同的 glibc.
static 不会解决所有问题, 若你又有使用 dlopen 开 .so,
若 .so 没做 version 的话, 反而又会遇到上面讲的 lib 混用的情况