→ 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 混用的情況