不同版本动态链接库是否会冲突？含跨平台及版本区分疑问

冲突风险肯定存在 #

如果你的动态库和客户程序依赖的第三方库（比如OpenCV、TBB）是同类型不同版本，且它们导出的符号（函数、变量名）完全一致，大概率会出现冲突。比如你的库调用OpenCV v1.0的cvLoadImage，客户程序调用v2.0的同名函数，系统加载时只会优先用PATH里找到的第一个版本，导致其中一方调用到错误的实现，轻则逻辑异常，重则直接崩溃。

能否各自绑定正确版本？ #

可以，但得看平台和第三方库的设计：

• Windows平台：如果第三方库的DLL带版本后缀（比如opencv_1.dll、opencv_2.dll），并且你和客户在编译时分别链接对应版本的导入库（.lib），就能实现各自绑定。因为导入库会明确记录依赖的DLL文件名，系统加载时会按文件名精准查找，不会混淆。但如果不同版本的DLL文件名相同（比如都叫opencv.dll），那基本没法共存，系统只会加载第一个找到的版本。
• Linux平台：需要编译时明确指定链接对应版本的库文件（比如你的库链接libopencv.so.1，客户程序链接libopencv.so.2），同时确保运行时系统能找到这些版本。可以通过LD_LIBRARY_PATH指定不同路径，或者编译时用-Wl,-rpath选项把库的私有路径嵌入到二进制文件里，让程序优先加载指定路径的库。

OpenCV带版本后缀的作用 #

当然有用！这种版本后缀就是为了解决多版本DLL冲突设计的。每个版本用不同的文件名，导入库（Windows）或软链接（Linux）对应绑定到该文件名，这样不同模块可以明确指定自己要依赖的版本，系统加载时不会出现误加载的情况，从根源上避免了同名DLL的冲突。

Linux平台的额外说明 #

Linux下动态库的版本管理依赖文件名和软链接：

• 通常库文件是libopencv.so.x.y.z（完整版本），同时有libopencv.so.x（主版本软链接）、libopencv.so（无版本软链接，一般指向最新版）。
• 如果编译时链接的是带主版本的软链接（比如libopencv.so.1），运行时会加载对应主版本的库；如果直接链接libopencv.so，可能会加载系统最新版。
• 还要注意：如果不同版本的库导出了同名且未做隔离的符号，即使文件名不同，全局符号表还是可能出现冲突。这种情况下，最好依赖第三方库本身的版本化符号修饰（比如OpenCV的符号是否带版本前缀），或者编译时用-fvisibility=hidden隐藏内部符号，只导出必要接口，减少冲突概率。

内容的提问来源于stack exchange，提问作者Linhh