静态库 lib 多几小问题

[staronline]

例如
静态库 a.lib 编译方式为: use mfc in static library ; release ;
在程序 b 使用 a.lib ,b的编译方式为 use mfc in share library

编译b时候提示很多错误，大致为很多**已经声明过
already defined in mfc42.lib(MFC42.DLL)

1.
这个问题我怎么解决？
我不想对a.lib 做任何改变

2.因为a.lib为release，b为debug时候编译出错
** already defined in Zip.lib
怎么解决？

3.如果 a.lib 为 use mfc in share library
b编译是不是可以为use mfc in share library 也可以为 use mfc in static library ？

4.从a.lib如果为 use mfc in static library，
是不是它编译的时候把部分需要的mfc东西编译到了a.lib之中?

[baojian88888]

1. 如果你不想对a.lib 做任何改变，应该没有方法解决
2. 不知道。
3. 应该可以。没试过
4. 是的

[BigFanOfCpp]

我觉得A.LIB不能做成use mfc in static library.

[BigFanOfCpp]

因为静态连接时,LIB包含DLL里函数的符号,所以会出现重复声明的问题.

[BigFanOfCpp]

不过有个极端的方法,就是修改DEF文件,将所有出错的函数的声明强行定义引出符号名.

[StarsWu]

不能.照你的做法,a.lib中将MFC42.dll中的一些函数原形加了进去,而你的b中有使用了MFC42.dll,因此会重定义.

[winthegame]

1. a.lib已经使用了静态链接mfc, 故 b 的编译选项应该使用 无 MFC的方式, 但因为a.lib 已经静态链接了mfc, 故而你可以将 a.lib 当作 mfc 类库的高级包装。b中可以放心使用mfc类。

2. 针对a.lib 为release. 使用b 也应当使用对应的release. 而如果要使用b 的 debug版本时，应该使用a.lib 的debug 版本.

3. 同 1

4. 不是，是把 MFC 整个导入到 a.lib中. 这是种比较变态的做法，如此一来，你的a.lib 尺寸凭空暴涨几百K. Debug可能涨到1M , 当然获得的好处是 a.lib从此可以独立编译。不再需要mfc的动态库支持，既是没有mfcxxxx.dll的支持也可以了, 当然与之链接的exe也是如此。

[baojian88888]

winthegame(120斤重的大青蛙)
分析的有道理，学习！

对于第2条
>>针对a.lib 为release. 使用b 也应当使用对应的release. 而如果要使用b 的 debug版本时，应该使用a.lib 的debug 版本
我实际一般也是这样做的，但是如果确定a.lib比较稳定后，一般我就只提供一个release版本的a.lib，连接时不论程序b是debug还是release，都是可以连接通过的

[sharkhuang]

有的库用的mfc release 有的用的mfc share 。冲突！可以在vc设置为一致就ok

[AntonlioX]

up