如何检测多个lib版本？ [英] How to detect multiple lib versions?
问题描述
大家好，
我创作了几个原生DLL（称之为A，B和C）。这些
库之间有相互引用（A调用B调用C）。
这些库是在调试中生成的，并且可供调用者使用。和
" release"版本。这些库的发行版本是A，B和C
（.lib和.dll），而调试版本是A_debug，B_debug和C_debug
（。 lib和.dll）。
现在，因为这些库保持内部状态并调用每个其他的b / b $ b $如果调用者与发布链接版本一个
库和另一个库的调试版本。在运行时，这会导致
同时加载某些库的两个版本。 （对于
示例，如果用户调用A的调试版本，调用B的调试版本，然后用户显式调用该版本
版本的B，然后B和B_debug将同时加载，每个都有自己的内部状态
。）
所以，如何检测程序何时引用我的库和另一个库的发行版本之一的调试版本？理想情况下，我希望
将一些魔法放入导致链接器错误的源代码中。
或者，我想我可能有某种方式的DLL初始化代码
检测何时加载了多个DLL实例。
TIA - Bob
" Bob Altman" < rd*@nospam.nospamwrote在
新闻：ek ************** @ TK2MSFTNGP06.phx.gbl：
大家好，
我创作了几个原生DLL（称之为A，B和C）。这些
库之间有引用（A调用B调用
C）。构建这些库并使其可以在
" debug"中使用。和释放版本。库的发布版本
是A，B和C（.lib和.dll），而调试版本是A_debug，
B_debug和C_debug（。 lib和.dll）。
现在，因为这些库保持内部状态并相互调用
，如果调用者与发布者链接，则会发生丑陋的事情
版本的一个库和另一个库的调试版本。在
运行时，这会导致某些库的两个版本同时加载
。 （例如，如果用户调用A的调试版本，调用B的调试版本，然后
用户显式调用发布版本B，然后B和
B_debug将同时加载，每个都有自己的内部
状态。）
所以，我如何检测程序何时引用我的一个库和另一个库的发行版的调试版本？
理想情况下，我想放导致
链接器错误的源代码中的一些魔力。或者，我想我可以有DLL初始化
代码，当某个DLL的多个实例已加载
时，它会以某种方式检测到。
TIA - Bob
另一种方法是自己专门拉入所需的库：
#ifdef _DEBUG
#pragma comment（lib，" xerces-lb_2D.lib"）
#pragma comment（lib，" xalan-lb_1D.lib"）
#else
#pragma comment（lib，" xerces-lb_2.lib"）
#pragma comment（lib，" xalan-lb_1.lib" ）
#endif // _DEBUG
（显然，这段代码正在使用xerces和xalan库）
全部你需要做的是确保路径设置为找到.libs。
我已经使用了同样的东西的其他3rdParty库 -
通常在头文件中。 （比如RogueWave的黄貂鱼）
Dave Connet
我原来的问题描述不太清楚。让我带上
另一次运行...
我正在努力解决类似于应用程序链接时发生的问题
debug C运行时库的一个版本，但应用程序
链接的库使用发布库。 C运行时库的版本。在C运行时库的情况下，你得到一个链接器错误（或者它可能是一个警告）
如果主应用程序和它的所有库链接与不同意在C运行时库版本（发布，调试，DLL或本地）上的
。
在我的情况下，我有几个我称之为A，B和C的本地库。
调用B和C，B调用C语言。当我在
$ b $中构建这些库时b释放配置，我创建A.dll（和A.lib），B.dll和C.dll。
此外，在发布中，配置，A指定B.lib和C.lib为
必需的输入库，B指定C.lib作为必需的输入库。
当我在Debug中构建这些库。配置，我创建了
A_debug.dll（和A_debug.lib），B_debug.dll和C_debug.dll。另外，在
" debug"配置，A根据需要指定B_debug.lib和C_debug.lib
输入，B指定C_debug.lib作为必需输入。所有
的结果是我有两套不同的内部一致的
库，一个编译用于发布，一个编译用于调试。
现在，调用这些库*的应用程序必须*使用一组库或另一组完全构建
。也就是说，应用程序必须
链接A.lib，B.lib和C.lib *或* A_debug.lib，B_debug.lib和
C_debug。 lib，但*永远*与A.lib和B_debug.lib。
所以，我正在寻找一种方法来实现某种检查以确保
调用这些库的
代码遵循此规则。我更喜欢
链接时间检查（类似于当主应用程序及其库
不同意C运行时库时会发生的情况）。但是，如果我不能这样做，我会解决
进行运行时检查。在运行时，如果应用程序调用A.lib，则会加载B.lib和
C.lib将被加载（因为A调用B和C）。如果应用程序直接
调用B_debug.lib，那么将加载B.lib和B_debug.lib（因为
将是C.lib和C_debug.lib）。我可以在
中找到某种类型的代码，用于检测这种情况的B和C的DLL启动代码。
嗯...我不知道知道这是否更清楚，但它肯定更长。
也许更多更好;-)
TIA - 鲍勃
" David Connet" < st *** @ agilityrecordbook.com写信息
新闻：pW **************** @ flpi146.ffdc.sbc.com ...
" Bob Altman" < rd*@nospam.nospamwrote在
新闻：ek ************** @ TK2MSFTNGP06.phx.gbl：
>那么，如何检测程序何时引用我的某个库的调试版本和另一个库的发行版本？
另一种方法是自己专门拉入所需的库：
#ifdef _DEBUG
#pragma comment（lib，" xerces-lb_2D.lib"）
#pragma comment（lib，" xalan-lb_1D.lib"）
#else
#pragma comment（lib，" xerces-lb_2.lib"）
#pragma comment（lib，" xalan-lb_1.lib"）
#endif // _DEBUG
谢谢戴夫。不幸的是，这对我的情况并没有帮助。 （请看看我的第二个帖子看看
。希望它比我的原始帖子更清晰。）如果调用者显式链接到<的调试版本
一个库和另一个库的发布版本然后事情就不用了b $ b工作正常。添加更多的库引用（尽管是正确的）
编程上没有帮助，因为链接器可能仍然会结束与不正确的库链接的
。
Hi all,
I have authored several native DLLs (call them A, B, and C). These
libraries have references between each other (A calls B which calls C).
These libraries are built and made available to callers both in "debug" and
"release" versions. The release versions of the libraries are A, B, and C
(.lib and .dll), while the debug versions are A_debug, B_debug, and C_debug
(.lib and .dll).
Now, because these libraries maintain internal state and call into each
other, ugly things happen if a caller links with the release version of one
library and the debug version of another library. At run-time, this causes
both versions of some of the libraries to be simultaneously loaded. (For
example, if the user calls into the debug version of A, which calls into the
debug version of B, and then the user explicitly calls into the release
version of B, then both B and B_debug would be simultaneously loaded, each
with its own internal state.)
So, how can I detect when a program references the debug version of one of
my libraries and the release version of another library? Ideally, I''d like
to put some magic into the source code that causes a linker error.
Alternatively, I guess I could have DLL initialization code that somehow
detects when more than one instance of the DLL have been loaded.
TIA - Bob
"Bob Altman" <rd*@nospam.nospamwrote in
news:ek**************@TK2MSFTNGP06.phx.gbl:
Hi all,
I have authored several native DLLs (call them A, B, and C). These
libraries have references between each other (A calls B which calls
C). These libraries are built and made available to callers both in
"debug" and "release" versions. The release versions of the libraries
are A, B, and C (.lib and .dll), while the debug versions are A_debug,
B_debug, and C_debug (.lib and .dll).
Now, because these libraries maintain internal state and call into
each other, ugly things happen if a caller links with the release
version of one library and the debug version of another library. At
run-time, this causes both versions of some of the libraries to be
simultaneously loaded. (For example, if the user calls into the debug
version of A, which calls into the debug version of B, and then the
user explicitly calls into the release version of B, then both B and
B_debug would be simultaneously loaded, each with its own internal
state.)
So, how can I detect when a program references the debug version of
one of my libraries and the release version of another library?
Ideally, I''d like to put some magic into the source code that causes a
linker error. Alternatively, I guess I could have DLL initialization
code that somehow detects when more than one instance of the DLL have
been loaded.
TIA - BobAnother way is to specifically pull in the required library yourself:
#ifdef _DEBUG
#pragma comment(lib, "xerces-lb_2D.lib")
#pragma comment(lib, "xalan-lb_1D.lib")
#else
#pragma comment(lib, "xerces-lb_2.lib")
#pragma comment(lib, "xalan-lb_1.lib")
#endif // _DEBUG
(Obviously, this code was making use of the xerces and xalan libraries)
All you need to do is make sure the path is set to find the .libs.
I''ve made use of other 3rdParty libraries that do the same thing -
usually in a header file. (Like RogueWave''s Stingray)
Dave Connet
My original problem description is less than crystal clear. Let me take
another run at it...
I am struggling with a problem similar to what happens if an app links with
the "debug" version of the C runtime library but a library that the app
links with uses the "release" version of the C runtime library. In the case
of the C runtime library, you get a linker error (or maybe it''s a warning)
if the main app and all of the libraries that it links with do not all agree
on the C runtime library version (release, debug, DLL, or local).
In my case, I have several native libraries that I''ll call A, B, and C. A
calls into B and C, and B calls into C. When I build these libraries in the
"release" configuration, I create A.dll (and A.lib), B.dll, and C.dll.
Also, in the "release" configuration, A specifies B.lib and C.lib as
required input libraries, and B specifies C.lib as a required input library.
When I build these libraries in the "Debug" configuration, I create
A_debug.dll (and A_debug.lib), B_debug.dll, and C_debug.dll. Also, in the
"debug" configuration, A specifies B_debug.lib and C_debug.lib as required
inputs, and B specifies C_debug.lib as a required input. The upshot of all
of this is that I have two different sets of internally consistent
libraries, one compiled for release and one compiled for debug.
Now, the applications that call into these libraries *must* build entirely
with one set of the libraries or the other. That is, an application must
link with A.lib, B.lib, and C.lib *or* A_debug.lib, B_debug.lib, and
C_debug.lib, but *never* with A.lib and B_debug.lib.
So, I''m looking for a way to implement some sort of check to ensure that
code that calls these libraries follows this rule. I would prefer a
link-time check (similar to what happens when the main app and its libraries
don''t agree on the C runtime library). But, if I can''t do that, I''d settle
for a run-time check. At run-time, if the app calls A.lib then B.lib and
C.lib will be loaded (because A calls into B and C). If the app directly
calls into B_debug.lib then both B.lib and B_debug.lib will be loaded (as
will C.lib and C_debug.lib). I could presumably have some sort of code in
the DLL startup code for B and C that detect this condition.
Huh... I don''t know if this is any clearer, but it''s definitely longer.
Maybe more is better ;-)
TIA - Bob
"David Connet" <st***@agilityrecordbook.comwrote in message
news:pW****************@flpi146.ffdc.sbc.com..."Bob Altman" <rd*@nospam.nospamwrote in
news:ek**************@TK2MSFTNGP06.phx.gbl:
>So, how can I detect when a program references the debug version of
one of my libraries and the release version of another library?
Another way is to specifically pull in the required library yourself:
#ifdef _DEBUG
#pragma comment(lib, "xerces-lb_2D.lib")
#pragma comment(lib, "xalan-lb_1D.lib")
#else
#pragma comment(lib, "xerces-lb_2.lib")
#pragma comment(lib, "xalan-lb_1.lib")
#endif // _DEBUGThanks Dave. Unfortunately, that doesn''t really help my situation. (Take a
look at my second posting. Hopefully it''s a little bit clearer than my
original posting.) If a caller explicitly links with the debug version of
one library and the release version of another library then things don''t
work correctly. Adding more library references (albeit correct ones)
programmatically doesn''t help things, since the linker may still wind up
linking with the incorrect library.
这篇关于如何检测多个lib版本？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
