DLL链接到静态库 [英] DLL linking to static libraries
问题描述
我们有一个可执行文件的项目，它在运行时加载DLL文件作为插件。
我们正在尝试一个新的插件，其中有很多库依赖关系，其中一些依赖关系是相同的库，但是其他插件链接的不同版本。
由于库依赖于不同版本的不同插件，想静态链接/构建任何依赖关系到新的插件 - 这样他们不能与旧的插件依赖关系冲突。据我所知，插件的依赖关系中没有任何东西需要导出，它们只是被插件使用。
可以这样做吗？ / p>
我已经尝试将visual studio中的所有静态库作为静态库，并将运行时设置为具有/ MD标志的多线程DLL，但是当我尝试构建dynamiclibB时。 dll，我得到链接器错误。如果我将dynamiclibB设置为静态库，那么它没有链接器错误。
我没有尝试将newplugin.dll链接到静态库版本还有，我觉得我有完全相同的情况，所以我看不出有什么理由在那里没有一个水平的工作。
t想将dynamiclibB构建为一个静态库，因为如果没有更改，那么可以更新newplugin.dll而不包括dynamiclibB.dll，如同在，来解耦更新过程。我认为，这个推理方式会表明我应该拥有所有的.dll，但是我觉得版本的冲突是令我担忧的。
我不能将这个插件做成静态的图书馆，因为他们需要在运行时加载。
目前，所有的内容正在以发布模式建立，以避免这种复杂性。
我缺少什么？
尝试图可能有助于了解情况：
program.exe
|
________________
| |
oldplugin.dll newplugin.dll
| |
dynamiclibA.dll dynamiclibB.dll
|
_________________________
| | |
staticlibA.lib slibC.lib slibD.lib
更新：
现在提供一些更多的信息，我知道发生了什么，并且知道更具体的细节实际上是相关的。
所以由dynamiclibA和staticlibA表示的库A是zlib。
我们正在编译的库（dynamiclibB）用于newplugin是PoDoFo。
我们得到的错误信息是：
错误19错误LNK2001：未解析的外部符号
_deflateInit_ E： \Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared错误20错误LNK2001：未解析的外部符号
_inflateEnd E：\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared错误21错误LNK2001：未解决的外部符号
_inflateEnd E：\Work\podofo_bin\src\libpng16.lib（pngread.obj）podofo_shared错误22错误LNK2001：未解析的外部符号
_deflate E：\Work\ podofo_bin\src\PdfFiltersPrivate.obj podofo_shared错误23错误LNK2001：未解决的外部符号
_deflate E：\Work\podofo_bin\src\libpng16.lib（pngwutil.obj）podofo_shared错误24错误LNK2001：未解决的外部符号
_deflateEnd E：\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared错误25错误LNK2001：未解析的外部符号
_deflateEnd E：\Work\podofo_bin\src\libpng16.lib（pngwrite.obj）podofo_shared错误26错误LNK2001：未解析的外部符号
_inflateInit_ E：\Work \podofo_bin\src\PdfFiltersPrivate.obj podofo_shared错误27错误LNK2001：未解决的外部符号
_inflateInit_ E：\Work\podofo_bin\src\libpng16.lib（pngrutil.obj）podofo_shared错误28错误LNK2001：未解析的外部符号
_inflate E：\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared错误29错误LNK2001：未解析的外部符号
_inflate E：\Work\podofo_bin\ src\libpng16.lib（pngrutil.obj）podofo_shared
将其余的放在答案中。 p>
在我的问题中，slibc.lib是libpng。 Libpng还需要zlib，但是它可以从源代码中构建它的解决方案。我们可以按照我们所希望的方式使用该项目的输出，如zlib.lib使用/ MD标志构建，而不链接错误。
也设法解决了 为什么 发生这个问题：
另一个stackoverflow问题是非常相关的： https://stackoverflow.com/a/6559315/78823
事实证明，zlib有一个#define ZLIB_WINAPI，它定义了通话约定是STDCALL，我不明白，但它导致链接器错误。另一个答案建议删除定义，我想这就是libpng使用它的zlib项目。
我猜测链接器错误的原因只发生在构建.dll并在构建.lib时消失，因为（如果我错了，请纠正我，我不完全明白这一点），构建一个.lib实际上并没有链接到所需的函数，所以会有只是将链接器错误传递到下一个级别;我想我们会在编译newplugin.dll时看到相同的错误（但是在不同的对象/项目中），但是在我们尝试其他的东西之前，我们没有足够多的检查。
We have a project which is an executable, which loads DLL files at run time as plugins.
We're trying to make a new plug in which has many library dependencies, and some of those dependencies are the same library but different versions that other plugins link to.
Because the libraries are depended on by different plugins at different versions, I would like to statically link/build any dependencies into the new plugin - that way they can't conflict with the old plugin dependencies. As far as I know, nothing in the dependencies of the plugin need to be exported, they're just used by the plugin.
Is it possible to do this?
I've tried building all the static libs in visual studio as static libraries with the runtime set to Multithreaded DLL with the /MD flag, but when I try to build dynamiclibB.dll, I get linker errors. If I set dynamiclibB to build as a static library, it doesn't have the linker errors.
I haven't tried linking newplugin.dll to the static library version of dynamiclibB yet, but I think I have exactly the same situation, so I see no reason why it would work there where it doesn't one level down.
I don't want to build dynamiclibB as a static library anyway, as it would be good to be able to update newplugin.dll without including dynamiclibB.dll if it hasn't been changed, as in, to decouple the update process. This line of reasoning would suggest that I should have .dlls for everything, but the conflicts of versions is what worries me, I think.
I cannot build the plugins as static libraries as they need to be loaded at run time.
Absolutely everything is being built in release mode for now, to avoid that complication.
What am I missing?
An attempt at a diagram that might help understand the situation:
program.exe
|
________________
| |
oldplugin.dll newplugin.dll
| |
dynamiclibA.dll dynamiclibB.dll
|
_________________________
| | |
staticlibA.lib slibC.lib slibD.lib
Update: Providing some more information now that I know what's happening, and know that more specific details are actually relevant. So library A, represented by dynamiclibA and staticlibA was zlib. The library we were compiling (dynamiclibB) for use in the newplugin was PoDoFo. The error messages we got were:
Error 19 error LNK2001: unresolved external symbol
_deflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 20 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 21 error LNK2001: unresolved external symbol
_inflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngread.obj) podofo_shared Error 22 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 23 error LNK2001: unresolved external symbol
_deflate E:\Work\podofo_bin\src\libpng16.lib(pngwutil.obj) podofo_shared Error 24 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 25 error LNK2001: unresolved external symbol
_deflateEnd E:\Work\podofo_bin\src\libpng16.lib(pngwrite.obj) podofo_shared Error 26 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 27 error LNK2001: unresolved external symbol
_inflateInit_ E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared Error 28 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\PdfFiltersPrivate.obj podofo_shared Error 29 error LNK2001: unresolved external symbol
_inflate E:\Work\podofo_bin\src\libpng16.lib(pngrutil.obj) podofo_shared
Putting the rest in an answer.
In my question, slibc.lib was libpng. Libpng also requires zlib, but it builds it from source inside its solution. We were able to use the output of that project in the way we desired, as in, zlib.lib built with /MD flag, without linking errors.
We've also managed to work out why this problem occurred: another stackoverflow question was very relevant: https://stackoverflow.com/a/6559315/78823
Turns out that zlib has a #define ZLIB_WINAPI which defined the call convention to be STDCALL, which I don't understand, but it caused the linker errors. The other answer suggests to remove the define, and I suppose that's what libpng did with its zlib project.
I'm guessing that the reason why the linker errors only occurred when building the .dll and disappeared when building the .lib is because (correct me if I'm wrong, I don't fully understand this), build a .lib doesn't actually do the linking to the required functions, so would have been just passing on the linker errors to the next level up; I think we would have seen the same errors (but in different objs/projects perhaps) when compiling newplugin.dll, but we didn't get far enough to check that before we tried other things.
这篇关于DLL链接到静态库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
