如果一个类里支持同时存在多个版本lib，并在编译时主动跟随系统VS版本。那就能完美解决问题了。
哦对。。。。
比喻说： @视窗.外部库.外部头文件"mytest.x64.h"
@视窗.外部库.x64.1 "mytest.x64.10.1.1.1.lib"
@视窗.外部库.系统需求.1 "10.1.1.1" 或者 "10.*.*.*" 支持通配符。
@视窗.外部库.x64.2 "mytest.x64.11.1.1.1.lib"
@视窗.外部库.系统需求.2 "11.1.1.1" 福寿 发表于 2022-10-24 04:54
lib是微软自己搞出来的一个格式，兼容性很差，比如2019生成的，到了2022就不一定可以用，就算你自己生成 ...
目前VS2015向上兼容了.微软官方就写着这个.https://learn.microsoft.com/zh-cn/cpp/porting/binary-compat-2015-2017?view=msvc-170 而且2019编译的Lib静态库2022是可以用的,我这两版本都有用.实测过的.
闭不闭源不说,但自己用C写一些功能,然后火山嵌入调用,就省事的多,编译还不带DLL.我个人是特别不喜欢带DLL的. @飞扬工作室
12楼说的应该是真的，在微软的公开文档中，
Visual Studio 2013 及更早版本中的 Microsoft C++ (MSVC) 编译器工具集不保证主版本间的二进制兼容性。 无法链接由这些工具集的不同版本生成的对象文件、静态库、动态库和可执行文件。 ABI、对象格式和运行时库不兼容。
我们在 Visual Studio 2015 及更高版本中改变了此行为。 由其中任一版本的编译器编译的运行时库和应用具有二进制兼容性。 这反映在 C++ 工具集主版本号中，对于自 Visual Studio 2015 以来的所有版本，该版本号都以 14 开头。 （对于 Visual Studio 2015、2017、2019 和 2022，工具集版本分别为 v140、v141、v142 和 v143）。 假设你具有 Visual Studio 2015 生成的第三方库。 你仍可在 Visual Studio 2017、2019 或 2022 生成的应用程序中使用它们。无需使用匹配工具集重新编译。 最新版本的 Microsoft Visual C++ 可再发行程序包（可再发行程序包）适用于所有版本。 我也检查了 Visual Studio Installer 能装的都是14 开头的版本 urenai 发表于 2022-10-28 21:55
我也检查了 Visual Studio Installer 能装的都是14 开头的版本
我是实测过的,因为我现在也是用VS2015封静态lib给火山用的,火山编译用的2019,用到现在也并无问题
页:
1
[2]