→ 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 _ZdlPv@GLIBCXX_3.4 + 0 0000000000202fa0 0000000600000007 R_X86_64_JUMP_SLOT 0000000000000000 _Znwm@GLIBCXX_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 混用的情況 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 218.161.21.57 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1535195469.A.461.html