Visual Studio生成CLR DLL时OpenCV相关LNK2005错误咨询

问题1：为什么仅调换输入库顺序的方案1可以解决重复定义错误？ #

Visual Studio 链接器对输入库的处理遵循先到先得的符号解析规则：

• 当你先链接opencv_world420d.lib（动态库导入库）时，链接器会先将cv::MatSize::MatSize这类符号标记为「需要从OpenCV动态库导入」的符号，后续处理Project2.lib时，碰到同符号的本地实体定义，就会触发「符号已定义」的冲突。
• 调换顺序后先链接Project2.lib，链接器会先拿到该符号的本地强定义，完成符号解析，后续处理OpenCV导入库时，碰到同符号的导入标记会直接忽略，不会触发重复定义报错。

问题2：为什么仅关闭Project3的/clr选项的方案2可以解决错误？ #

这是/clr编译模式和原生C++模式对inline函数的符号处理规则不同导致的：

• 原生C++模式下，未被实际内联展开的inline函数会被标记为弱符号（COMDAT），链接器碰到多个重复的弱符号时会自动选择其中一个合并，不会触发重复定义错误。
• 开启/clr编译时，编译器的托管编译逻辑会修改inline函数的生成规则：未被内联的inline函数会被生成为强外部符号，不会标记为COMDAT，多个编译单元生成的同符号会被链接器判定为重复定义。
  关闭/clr回到原生C++编译逻辑后，重复的inline弱符号会被自动合并，错误自然消失。

问题3：OpenCV将内联函数的实现放在hpp文件中的设计是否安全合理？ #

该设计是安全合理的，完全符合C标准规范，也是C开发的常规操作：

• 按照C++标准，内联函数的定义必须对所有调用它的编译单元可见，否则编译器无法在调用点完成内联展开，将实现放在头文件（hpp）是唯一可行的方案。
• 对于cv::Mat这类高频使用的轻量类，小函数内联可以大幅降低调用开销，提升运行性能，是典型的性能优化设计。
  你碰到的问题属于/clr特殊编译模式下的适配问题，并不是OpenCV的设计缺陷，正常原生C++项目使用该设计不会出现冲突。

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