Linking to a native C++ DLL from a C++/CLI project, getting many linker errors.
I was hoping someone would be kind enough to help me with this.
I have a DLL that is written in native C++, and it's quite complicated, and is dependent on many other libs, both static and DLL, but this DLL seems to build just fine. No compiler errors or linker errors.
This DLL mainly has one exported class. I wish to instantiate this class in a C++/CLI application.
So:
1. I set up the C++/CLI project in Visual Studio 2008
2. I pointed the linker input to the DLL's corresponding lib.
3. I included the necessary header file for the class that I want to instantiate
4. I instantiated my object right inside the main function.
5. I hit 'build'
And from this I get over 160 linker errors; a combination of unresolved external symbols and unresolved tokens. The crazy thing is, none of these symbols are from the class that I am trying to instantiate. Rather, they are from other libraries that my DLL class is dependent on.
I tried commenting out the actual instantiation of the object, and I still get these linker errors, which means that the simple act of including this header file is enough to cause the errors.
I'm not quite sure what to make of this. If I create a native C++ project, and try to instantiate this DLL class from within it, it works fine, with no linker errors.
Alternately, if I create a new native C++ DLL, one that is far simpler and has no external dependencies, I can quite easily instantiate the simpler class in my C++/CLI project.
Does anyone know what I'm doing wrong? Is there something about .NET that requires to link not only to my DLL, but all of that DLL's dependencies as well?
Oh, and by 'linking to a DLL', what I mean is, when I build the DLL, it outputs two files: a lib and a dll. I link to the lib as if it were a normal static lib, and I guess this does some magic or something, so that my program knows to load the right DLL and stuff.
Ok, so over the past day, I've been doing some tests. I feel like, even though I have some new information, I haven't really made any progress on this issue.
Here's the deal, I have a DLL written in native C++ whose primary job is displaying a scene. It is heavily-reliant on OpenSceneGraph for all of its scene management and rendering. It is written so that other apps can link to it, if they need to display a rendering window, or whatever.
And it works fine, if the app is in native C++. But this one app I'm writing, which must be managed, is in C++\CLI. And with that, I get over 164 'unresolved token / external symbol' errors.
However, none of these errors concern symbols that are in my DLL. They all concern OSG-related symbols, and if I link my C++\CLI application to those OSG libraries, the errors go away.
But why do I have to do that? I don't when my app is native: I simply link to my DLL, and it works fine, presumably because my DLL has been linked to the OSG libraries already, and so further linkage to those libraries aren't needed.
But the managed app seems to require it for some reason, which is quite messy.
But to further complicate things, it does not seem to be a general rule that managed apps require direct linkage to all libraries in a dependency chain. In other words, I ran a test where I created two native C++ DLLs, one of which depended on the other, and then I tried linking my C++\CLI app to the dependent so as to create the following dependency chain:
This works fine! I can even instantiate class B (which has, as a member, an instance of class A) from within the C++\CLI app, and it all works fine!
So there's something about these OSG DLLs that is causing this problem, which again only occurs when trying to link to a managed app. Hmmmm...
Here's the deal, I have a DLL written in native C++ whose primary job is displaying a scene. It is heavily-reliant on OpenSceneGraph for all of its scene management and rendering. It is written so that other apps can link to it, if they need to display a rendering window, or whatever.
OSG --> Visual.DLL --> App
And it works fine, if the app is in native C++. But this one app I'm writing, which must be managed, is in C++\CLI. And with that, I get over 164 'unresolved token / external symbol' errors.
However, none of these errors concern symbols that are in my DLL. They all concern OSG-related symbols, and if I link my C++\CLI application to those OSG libraries, the errors go away.
But why do I have to do that? I don't when my app is native: I simply link to my DLL, and it works fine, presumably because my DLL has been linked to the OSG libraries already, and so further linkage to those libraries aren't needed.
But the managed app seems to require it for some reason, which is quite messy.
But to further complicate things, it does not seem to be a general rule that managed apps require direct linkage to all libraries in a dependency chain. In other words, I ran a test where I created two native C++ DLLs, one of which depended on the other, and then I tried linking my C++\CLI app to the dependent so as to create the following dependency chain:
DLL A --> DLL B --> C++\CLI App
This works fine! I can even instantiate class B (which has, as a member, an instance of class A) from within the C++\CLI app, and it all works fine!
So there's something about these OSG DLLs that is causing this problem, which again only occurs when trying to link to a managed app. Hmmmm...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement