|
本帖最后由 aiqinxuancai 于 2023-10-11 15:50 编辑
由于误报实在是太多了,又限制了写新的支持库,前几日痛下决心把我的一个项目升级到了VC2017链接器。
过程坎坷。。。
首先就是缺少符号,某个Json支持库提示缺少_timezone符号,看起来是在vc6以后就不存在的c++符号,但是我对这个库的使用很多,实在没办法简单的替换掉。
看到了原生legacy_stdio_definitions.lib的启发,不如...自己写一个_timezone链接进去。
于是写了此项目,简单实现了_timezone符号
https://github.com/aiqinxuancai/legacy_link_definitions
编为x86+Release的lib放在链接器目录,在ini文件的extra_args写成这样既可。
extra_args=/DYNAMICBASE "legacy_stdio_definitions.lib" "legacy_link_definitions.lib"
简单的符号缺少,比如全局函数或全局变量,使用这种方法可以很快的处理,就是一些Xlen等std的类方法可能就比较麻烦了。
---------------------------------------------------
说说后续
然后就是可以编译了,但是编辑后运行就崩溃。
从堆栈可以看出是标准输出崩了,找遍了模块找到了日志库里有调用,接下来测试发现,VC2017的链接器用不了标准输出...
解决掉以后,编译再运行,又崩溃。
根据子程序名的崩溃定位到是Gdiplus模块的某个类COM的释放,过程就不讲了,崩溃点在字节流释放部分,即IStream的释放函数。
上面为原始代码,下面是我直接封装了个DLL来做释放,如果你有兼容VC6和其他链接器的汇编方法,欢迎发出来。https://github.com/aiqinxuancai/FreeCOMObject
(为啥这么常用的模块在VC2017链接器下崩溃论坛就没人讲过??)
接下来就大功告成了,误报减少了很多。
后续又自己提取了VC2022的链接器,误报进一步减少了。
以后的支持库终于可以用c++20来写了。。。
补充内容 (2023-10-19 15:43):
这几天发现了最后一个COM释放崩溃的原因,是因为在VC2010以后的链接器默认开启了DEP兼容,我们需要链接器添加 /NXCOMPAT:NO 参数对其进行关闭
补充内容 (2023-12-27 16:25):
最后还是换回了VC6, 因为好像还是有不明原因第三方库崩溃
补充内容 (2024-2-2 16:20):
link.ini 附加链接参数加/FORCE 可解决符号重定义的问题(只保证编译成功,不保证一定会正常)
补充内容 (2024-2-2 16:45):
又换回了VC2022,舒服了 |
评分
-
查看全部评分
|