具有依赖关系的静态库 [英] Static library with dependencies

查看:177
本文介绍了具有依赖关系的静态库的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

e.exe 链接到我的自定义静态库 c.lib ,它使用Win32 API w.dll w.dll 位于C:\Windows \System32,其导入库 w.lib 在Windows SDK目录中。 Shell w.lib c.lib 或<$ c中列为附加依赖关系 $ c> e.exe 项目? ( e.exe 在这两种情况下都可以成功构建。)什么是最佳实践,为什么?我想 e.exe 不应该知道 w.lib



c.lib 仅供一组开发人员共享(不会发送给客户) 。



TEST :我使用VS2008和dumpbin工具测试这两种情况,结果如下:




  • 案例1: w.lib 添加为 c中的附加依赖关系 .lib 项目。



dumpbin / archivemembers c.lib 输出列出 w.dll中的偏移量和.obj文件从 c.lib 项目作为存档成员。




  • 情况2: w.lib 未添加为附加依赖< c> c.lib ,但在 e.exe ul>

    这次,dumpbin输出只包含 c.lib 的.obj文件,以及 c.lib 小于案例1中



    c.lib 作为 w.exe 项目中的附加依赖性。)



    注意:我使用的是 w.lib w.dll 图书馆,但他们可以是例如Userenv.lib和Userenv.dll或Version.lib和Version.dll ...

    解决方案

    我认为你误会了什么创建归档文件和导入归档文件。



    按照您在注释中正确推测的方式创建归档文件,创建一个包含已编译的.objs的统一文件。现在,这可以包含任何你喜欢的代码,包括但不限于对库的动态调用。导入库是一个库,它包含一个专门进行这种调用的obj,其想法是通过导入它,您的exe可以找到适当的符号(它们必须在您创建的可执行文件中)。



    w.lib 创建 c.lib 的过程只需提取 w.lib 的对象,并将它们附加到 c.lib 中的对象集合。实际上, c.lib 成为导入库+代码。



    我认为你应该这样做吗?不是真的 - 它可能会导致混乱,因为 e.exe 依赖;我认为你应该明确地让这可见,而不是试图隐藏它。也就是说,这只是一个建议,而不是一条规则。


    e.exe is linked against my custom static library, c.lib, which uses Win32 API defined in w.dll. w.dll is located in C:\Windows\System32 and its import library is w.lib, located in Windows SDK directory. Shell w.lib be listed as Additional Dependency in c.lib or e.exe project? (e.exe builds successfully in both cases.) What is the best practice and why? I guess e.exe should not know about w.lib.

    c.lib is intended to be shared among a group of developers only (not to be shipped to customers).

    TEST: I used VS2008 and dumpbin utility to test both cases and here are results:

    • Case 1: w.lib added as Additional Dependency in c.lib project.

    dumpbin /archivemembers c.lib output lists both offsets in w.dll and .obj files from c.lib project as Archive members.

    • Case 2: w.lib not added as Additional Dependency in c.lib but in e.exe project:

    This time, dumpbin output contains only .obj files of c.lib and the size of c.lib is smaller than in Case 1

    (c.lib was added as Additional Dependency in w.exe project in both cases.)

    NOTE: I used w.lib and w.dll here as fictional, generic names for Windows libraries but they could be e.g. Userenv.lib and Userenv.dll or Version.lib and Version.dll...

    解决方案

    I think you're misunderstanding what creating an archive and an import archive does.

    Creating an archive, as you've rightly surmised in comments, creates a unified file containing compiled .objs. Now, this can contain any code you like, including but not limited to dynamic calls to libraries. An import library is a library that contains an obj that exclusively makes such calls, the idea being that by importing it, your exe can find the appropriate symbols (they must be in the executable you create).

    The process of creating c.lib from w.lib simply extracts w.lib's objects and appends them to the collection of objects in c.lib. In effect, c.lib becomes an import library + code.

    Do I think you should do this? Not really - it might lead to confusion as to what e.exe depends on; I think you should explicitly make this visible rather than trying to hide it. That said, that's a recommendation only, not a rule.

    这篇关于具有依赖关系的静态库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆