这次项目开发中将词汇树训练和图像相似匹配的模块编译成lib给分布式三维重构系统调用遇到一个十分诡异头疼的问题,起因还是因为硬盘空间的问题将包括静态库的解决方案移动到了另一个磁盘,因为调用的项目中直接使用的#pragma comment(lib,“lib的绝对路径”),头文件附加include目录里包括lib库的目录,觉得这样可以保证和lib库的同步,于是就相应修改了lib绝对路径的地址,不过出人预料的是无论怎么修改总是返回一个链接错误,打不开原来路径指向的lib库,很自然的怀疑是不是还有其他cpp文件有链接库的宏,于是在整个坚决方案里搜索了一下可是没发现;
So,开始纠结了,于是一顿瞎试,将库拷入调用项目本地目录,使用链接项和宏都试了,只要是填写正确的路径(不管改名不改名)都返回最初的那个链接错误,只有路径错误的时候没有(链接时只要有错误就停止了,就像找不到头文件一样);于是有些郁闷了,一时间没了头绪(甚至觉得编译器傻逼了,记住了原来库的名字绑定了链接地址,多么滑稽的的念头,显然不切实际,至少改了名字还是如此呀,不要有这么强的质疑精神)
总的说来还是自己编写代码的习惯不够严谨,写测试用例不遵循严格的代码规范,一向是随兴所至信手拈来,写完后又想留下自己的思维脉络很多时候测试代码也不删除的,这里给自己埋了一个地雷更是因为自己连注释掉测试代码都忘了,以至于项目集成越来越复杂出现问题时很难定位溯源;以后写测试或者临时有不同的意图不要随便在源代码上修改要遵循统一的严格规范,词汇树模块一开始作为一个单独的可执行项目开发的也做了不少性能方面的测试留下了不少 测试代码(自然这对lib库来说完全没必要),另外64位和32项目也是共用同一套源代码文件(根据不同的测试意图有专门定制自身的测试样例,所以整体上逻辑不难么明晰了)
所以问题的根源是,我在lib项目的一个cpp文件里使用了最初的宏(Vocalbulary.cpp中使用 #pragma comment(lib,"D:/study/source code/Cmake_cmvs_Win_Linux-fix1/cvms_Win_Linux-fix1/VC/Release/Vocalbulary search.lib")) , 一开始的方向是正确的,现在想来也明显是唯一的合理解释,只是没有想到是自己买了这门一个无语的地雷(刚好在移动项目在磁盘中的目录时踩到了),怎么也没想到自己当时怎么脑残在自身项目上测试刚刚生成的lib库(应该是图个方便,不用引用头文件的想法,一直以来都是问题的根源),后来修改了部分代码也就改回lib选项直接生成,忘了将宏定义那句注释掉)这就埋下了一个地雷,只要不踩到(对应的链接地址有lib库 其实也没用 只是重复用不上的信息)就不会有任何问题;
这次教训也不是全无收获,lib库是不可以调用其他lib库和动态链接库了,这里在项目选项里没有链接选项就可以说明,但是可以使用宏定义,我想编译器在当前生成链接库的时候会直接忽略掉链接库的操作(不管是实际代码绑定还是符号绑定),似乎把链接的动作记忆在lib库里延迟到被调用时进行(我想就是解析相应的obj文件的时候Vocalbulary.cpp发现链接宏定义执行实际的未完成的链接动作(只针对当前cpp文件??),这也解释了后面出现的无法打开Vocalbulary.obj文件,当时觉得很诡异没有去深究,其实这是最好的定位线索,唉...);所以总体来说静态库原则上是不能链接其他库的,需要时(如opencv的库)实际操作时时延迟到调用时被链接完全;
So,开始纠结了,于是一顿瞎试,将库拷入调用项目本地目录,使用链接项和宏都试了,只要是填写正确的路径(不管改名不改名)都返回最初的那个链接错误,只有路径错误的时候没有(链接时只要有错误就停止了,就像找不到头文件一样);于是有些郁闷了,一时间没了头绪(甚至觉得编译器傻逼了,记住了原来库的名字绑定了链接地址,多么滑稽的的念头,显然不切实际,至少改了名字还是如此呀,不要有这么强的质疑精神)
总的说来还是自己编写代码的习惯不够严谨,写测试用例不遵循严格的代码规范,一向是随兴所至信手拈来,写完后又想留下自己的思维脉络很多时候测试代码也不删除的,这里给自己埋了一个地雷更是因为自己连注释掉测试代码都忘了,以至于项目集成越来越复杂出现问题时很难定位溯源;以后写测试或者临时有不同的意图不要随便在源代码上修改要遵循统一的严格规范,词汇树模块一开始作为一个单独的可执行项目开发的也做了不少性能方面的测试留下了不少 测试代码(自然这对lib库来说完全没必要),另外64位和32项目也是共用同一套源代码文件(根据不同的测试意图有专门定制自身的测试样例,所以整体上逻辑不难么明晰了)
所以问题的根源是,我在lib项目的一个cpp文件里使用了最初的宏(Vocalbulary.cpp中使用 #pragma comment(lib,"D:/study/source code/Cmake_cmvs_Win_Linux-fix1/cvms_Win_Linux-fix1/VC/Release/Vocalbulary search.lib")) , 一开始的方向是正确的,现在想来也明显是唯一的合理解释,只是没有想到是自己买了这门一个无语的地雷(刚好在移动项目在磁盘中的目录时踩到了),怎么也没想到自己当时怎么脑残在自身项目上测试刚刚生成的lib库(应该是图个方便,不用引用头文件的想法,一直以来都是问题的根源),后来修改了部分代码也就改回lib选项直接生成,忘了将宏定义那句注释掉)这就埋下了一个地雷,只要不踩到(对应的链接地址有lib库 其实也没用 只是重复用不上的信息)就不会有任何问题;
这次教训也不是全无收获,lib库是不可以调用其他lib库和动态链接库了,这里在项目选项里没有链接选项就可以说明,但是可以使用宏定义,我想编译器在当前生成链接库的时候会直接忽略掉链接库的操作(不管是实际代码绑定还是符号绑定),似乎把链接的动作记忆在lib库里延迟到被调用时进行(我想就是解析相应的obj文件的时候Vocalbulary.cpp发现链接宏定义执行实际的未完成的链接动作(只针对当前cpp文件??),这也解释了后面出现的无法打开Vocalbulary.obj文件,当时觉得很诡异没有去深究,其实这是最好的定位线索,唉...);所以总体来说静态库原则上是不能链接其他库的,需要时(如opencv的库)实际操作时时延迟到调用时被链接完全;