情况

我正在使用Visual Studio 2008 SP1(专业版,适用于32位和64位版本).我正在寻找一种解决方法,我认为这是Visual Studio中一个非常无益的" 限制 ".

我觉得很奇怪,在Visual Studio连接器和编译器不以DLL文件的创建时间这一权利,自动扫描所有导出的符号所有指定的静态库中所示的相同的方式构建一个导入库和导出文件,并在一StackOverflow评论.我确认仅仅在组成静态库的文件中应用__declspec(dllexport)和__declspec(dllimport)属性类,函数和数据声明是不够的 .

链接器不扫描导出符号的所有静态库,因此不会将它们拉入DLL文件(符号必须由.objDLL链接命令行上的文件或我在下面显示的其他方式引用).如果没有对每个导出符号的显式引用,仍可能会创建DLL文件,但不会创建其关联的导入库文件.

根据我的收集,Microsoft建议使用LIB.EXE 来创建DEF文件,但不幸的是,LIB.EXE页面应用了一个约束:

请注意,如果您在创建导入库之前创建导入库,则在构建导入库时,必须在构建导入库时.dll传递相同的目标文件集.dll.

鉴于我在新的构建环境中也使用了CMake,这是一个不幸的约束.CMake隐藏了实际传递给链接器的细节(我认为这在99%的时间里都是好事),但在这种情况下我需要在CMake执行时访问一些信息,而不是然后使用手工制作的脚本或其他脆弱的skulduggery.

问题:

如何强制DLL链接器解析构成DLL文件的所有静态库中的所有导出符号,这不会导致脆弱性和额外的构建逻辑维护工作？在这里考虑全自动化,并记住我需要多次为多个不同的DLL执行此操作.

我的问题是:

1. 如何仅使用CMake语法获取最终DLL链接命令行上使用的目标文件和静态库集？

2. LIB.EXE行(用于生成DEF文件的那个)上列出的文件的顺序是否必须与DLL链接行上使用的顺序完全匹配？

3. 使用LIB.EXE方法生成DEF文件可能会遇到其他困难吗？

4. 有没有更好的方法来解决这个问题,在调用最终链接之前不需要调用单独的实用程序,例如LIB.EXE ？我担心LIB.EXE链接本身之外的额外构建开销会再次重新扫描所有静态库 ,即使它只是在单独的执行中写出来.

非答案:

以下是我现在无法考虑的解决方案:

1. 在原始文件.h或.cpp文件之外的任何地方手动指定未引用的符号,因为每次开发人员忘记更新列出(很可能是名称错位的)符号名称的文件时,这样做会中断.并且它将打破关于未解析符号的非用户友好链接器错误,这对于开发人员来说将是昂贵的调试.这个非答案包括以下方法:

   1. 明确地将.obj文件添加到DLL链接命令行中(其中的变体包括添加"假" .obj文件,这些文件具有对未引用但导出的符号的虚拟引用(并注意这是我的旧构建环境今天所做的,并且它很臭) ),和,

   2. 手工制作DEF文件以包含未引用但导出的符号,以及 …

以下是make CMakeLists.txt的片段:

add_library(foo-object OBJECT src/foo.cpp)
target_include_directories(foo-object PUBLIC include)
add_library(foo SHARED $<TARGET_OBJECTS:${PROJECT_NAME}-object>)
add_library(foo_static STATIC $<TARGET_OBJECTS:${PROJECT_NAME}-object>)

现在,这一切都很好,两个库都生成了.但是当我尝试使用它时遇到问题:

add_executable(bar src/main.cpp)
target_link_libraries(bar foo)

Target bar不编译,因为不传播来自foo-object的include目录.如果我也target_include_directories直接添加foo,一切都会正常编译.

我如何制作foo并foo_static自动使用(并根据它们转发内容)包含目录foo-object？