We have an excellent MFC/C++ project that handles the data to and from a legacy database. All classes are exported with AFX_EXT_CLASS (which is dllexport if i am not misunderstanding it). I am currently writing a wrapper so that we can use it in C# applications. This is my first real wrapper, so please bear with me.
This is what i have done:
Compiled the project with /Yc /Gm- /Clr. It produces a .lib and a .dll.
I have access to the source so, i added the path of the header files in my C++/Cli project. It therefore recognises the types.
I added the .lib to the linker input in the C++/Cli project.
I have added the .dll as a reference in the C++/Cli project.
In the C++/Cli project, i have a stdafx.h that looks like the stdafx.h in the native project.
If i understand this correctly, the .lib is the implementation, the .dll is the "wrapper" to be able to reference it as a .net-dll, and the header files are the class definition.
Now, i can define native objects in the C++/Cli project, but when i access functions therein and try to build it, it throws external reference not found errors on the objects that i am trying to define.
This is understandable because it can not know that the header files point to the implementation in the .lib. The header files are used as is.
What am i doing wrong? Am i supposed to point at the header files? Should it not use the .dll to find the class definitions that are implemented in the .lib file? Should i create a .def file to point at the library?
There seem to be a missing piece to this puzzle and i am expecting to experience an aha-moment any moment now...
Please note that this is not a general linkage question, it is specifically about the practical use of AFX_EXT_CLASS exported classes, MFC and C++/CLI.
Cheers and thank you
You don't need your step 4. Also, try to don't use Precompiled headers like stdafx.h in your project, Go to C/C++ -> Precompiled Headers -> Not using precompiled headers and Check Linker -> Additional Dependecies -> Inherit from parent or project defaults. Finally, check the error message link if it's point to windows library use missing try to include .lib library using #pragma comment (lib, "yourlib.lib")
Related
Why must we reference projects, for C++, in Visual Studio 2013 when we intend to use a method from a referenced project? I'm confused because we use the #include preprocessor directive, which is copying & pasting the code we intend to use into the same header file which is still above/before the method that is actually using it.
Basically, even if I have all the projects in the same solution file, and the header files are correctly finding each other (intellisense doesn't complain/ proper linting occurs), I still get linker errors. But even if referencing projects is purely about resolving linker errors, if intellisense can peek/show definition to the code I am importing from a separate project, doesn't that mean Visual Studio also knows which project I'm linking against?
There must be a reason why, we both #include and reference the included projects even now in VS 2013. Could someone help explain why?
"There must be a reason why, we both #include and reference the included projects even now in VS 2013. Could someone help explain why?"
Including header files allows to use the declarations (of functions, classes or structs) from there. But to get a completely executable program there's more necessary:
The compiler needs to know where to get the #include'd header files from
The compiled source code from a different project needs to be linked to the final artifact
The linker needs to know where to get the linked libraries from
If you have header only libraries, the least 2 points won't be relevant, but Visual Studio would still need the project reference for resolving the header file pathes.
For Visual Studio in particular there's also the #import directive available, that makes it easier to link against shared libraries (and keep those as standalone projects, instaead of referenced ones from the same solution).
No, it is computationally infeasible for a linker to magically guess which definitions you want to link into your project at any given time. It's a good thing that it does not attempt to do so.
The C/C++ compiling process has two steps:
compile (.c/.cpp) source code into a lib (requires external .h files)
link all necessary lib files into an executable (requires both the own compiled lib files and external lib files. After all, the external .h file only contains the definition)
Everybody, I am a beginner and I have still have some things I am confusing about.
I have a program qt which I want to include a extern library. Generaly, to include a extern library I use the macros :
INCLUDEPATH += "path/to/the/include/headers/file"
LIBS += -L"path/to/where/the/lib/are" \
-llibname // .a for gcc .lib for mscv
Then I can use the library in my program. But at the end the qt aplication program use the .dll associated to the lib name. So my question, why can't we use directly the .dll in Qt ? I don't know very much the difference between a ".lib" and ".dll" execpt a ".dll" is used at the runtime.
My problemen is have a library with only the dll and the include headers file. Is there a way to use this library like this or I must have the .a or .lib associated ?
EDIT :
Ok now,thanks to the useful advice, I understand better the difference between, .lib and .dll and how to use a dll without a .lib with only header. But I am having a issue. With the header, I can create the object, the compilator doesn't bother about it can't find the object and its method, but When I compile, I have some problems about "undefined reference to a method".
If I correctly understand, the reference cannot be found because the reference are defined in the .lib, that's why it can't find it. So my question :
How can I say to the compilator that the reference to a method will be defined at runtime and not at compile time ?
EDIT2 :
Ok so apparently you can get a pointer of an object with a dll but you can't use its methods, so I think I am facing the wrong way. Thanks again for you answer.
Best regards,
There are 2 types of lib file, see this asnwer: https://stackoverflow.com/a/2375144/2064646
You can just use a .dll without .lib file, but through GetProcAddress function.
I don't know how to do the following:
I'm using MS Visual C++ 6.0
I have a Win32 DLL project which is compilable.
I have another project, this time a Win32 Console project which uses
the DLL by including it's header file and linking the .lib file of
the DLL.
Now I want to have another project, similar to the second BUT without using the header file and the lib file.
Is that possible? Everywhere I read you need either dll+lib+h or dll+h. If thought if you know the interfaces, a DLL file is sufficient?
Btw, by "using a DLL" I mean, using the Classes and Functions defined in the DLL.
It is possible if you just have plain "extern C" functions. If this is the case the approach could be loading the dll with LoadLibrary, and then import each function with GetProcAddress, of course you need to know the function signature to create a properly declared function pointer. Using classes per contrary is almost impossible.
If your DLL contains classes, there are good chances that it is a COM component.
If this is the case, the #import directive (that you use like #include) builds some temporary include files containing the interface details. You should use COM to access your objects.
Otherwise, if you have a 'plain' DLL with C++ classes, you could access the exported symbols using linker: instruct it to dump the map (see here), to know the mangled names. But I don't think that's possible to build manually the interface...
I'm building a socket program in Visual Studio 2003 .NET
I #include <winsock2.h> header file but also noticed that I had to link in the WS2_32.lib to fix the unresolved winsock function errors.
In other homework projects, I just added a header file and used it's functions - without adding the corresponding library.
How is this so?
Are some standard header file libraries already pre-linked in Visual Studio or something else?
Thank You!
The socket functions are actually implemented in ws2_32.dll. In order for the linker to be able to find them, you need to add the ws2_32.lib import library to your project. Note that the import library does not contain the actual code for the functions, but only information about where to find the actual functions (in ws2_32.dll).
You don't mention which other header files you're referring to, but if it's something like <string.h> then that is already in the MSVC runtime library; if it's something like <windows.h> then those functions are provided by import libraries such as kernel32.lib, user32.lib, and gdi32.lib. Those libraries are probably already included in your linker settings.
By default, Visual Studio includes the most commonly used Win32 .lib files, e.g. kernel32.lib, user32.lib, advapi32.lib etc. For more esoteric libraries, you need to add the .lib files yourself.
By default Visual Studio will link against the standard library, so if you are including a header that is part of that then you don't need to explicitly add the library. This is true for things like stdio.h, iostream and stdlib.h.
There are also some header files such as those used by the Standard Template Library (someone will be along in a minute to say that it's actually just called the 'Standard Library', but most books I've ever read, and Microsoft's docs too refer to the STL) such as <vector> and <list> which define all their code as templates that get expanded into the full functions by the compiler so that they don't need to link in a library.
A slight aside: there's also a mechanism for automatically linking against a library. Just add:
#pragma comment(lib, "ws2_32.lib")
somewhere in your code. Boost uses this technique so that it links against the correct build of the library depending on your compiler settinsg.
This has nothing to do with Visual Studio; this is how compilation of C/C++ works.
All a header does is declare or define symbols. Functions, variables, typedefs, classes, etc.
A header can say:
int SomeFunction();
This is a function declaration. In order for you to compile code that uses SomeFunction, you must declare that SomeFunction exists. And this declaration must be made before your code that uses it.
These declarations are typically in header files.
However, a declaration is also a promise. A function definition is the actual C/C++ source code that makes the function work. A declaration says, "at some later point, you will be able to find the definition of this." This is a promise you are making to the compiler and linker.
You cannot successfully link C/C++ code unless all declarations in use have a definition. Some of these definitions come from your own compiled code, but some of them come from external libraries. External libraries have header files that provide the declaration of C/C++ functions, types, etc. But they also have library files (in VC++, these use the .lib extension) that provide the definition of those functions.
If you use declarations from a header, without linking to the library files that provide the definition of those symbols, you get a linker error.
Note that header files can contain definitions as well; much of the C++ standard library, and must of Boost is defined solely by header files. So there are no libraries to include. The library's documentation should tell you whether there is a .lib to link against or not.
I have been learning opengl for about 4-5 months now.
I am ready to stop using glut(a helper library that obfuscates many difficult / tedious aspects of opengl programming )
Problem is, I feel I have removed all refrences to glut.h, as well as all function calls within glut, but when I run my application it is still trying to link to glut32.dll.
Generally so I and others can learn for later,
How can I tell which libraries an excutable/source-code need and why(function/header wise), either before or after compile?
I am using VS2010 but cross compiling this on a linux box with g++
In this specific instance I don't have the dll listed as an additional dependency . But I do see glut.h in the extrenal dependencies folder...i just cant remove it
Thank you
Dependency Walker is your friend for examining the dll dependencies of compiled binaries.
The principal problem is of course, you have added glut.lib or glut32.lib to your project someplace. Its probably in the Project Properties > Linker Settings > Additional Libraries, or some source file contains a #pragma something like this :-
#pragma comment(lib, "glut32.lib")
Look at the linker properties for you project(s). The dll, or rather, the corresponding .lib should be listed there under "additional dependencies".
Edit:
By the way, including a header and linking a library (or a dll) are two different things. You may be including a header somewhere, but not linking to the corresponding library. In that case, the linker will give you an error. On the other hand, you may not be including the header, and not using the library at all, but you may still be linking to it.
In this case it seems like we have both. If glut.h is in the external dependencies folder then you must be including it somewhere in your code. Try using find-in-files to look for it. Or delete it from your system altogether and try to compile.
Every exe/dll has something called an Import Address Table (IAT) which is information stored in the PE (Portable Executable: window's executable file format) file's header about what dlls the loader needs to load when the module in question is loaded. You can use tools like PE Viewer or PE Explorer to view this information or write your own (this is more difficult). What you will see are libraries that are statically linked to your executable. If you don't see glut32.dll in any of those files, it is possible that it is loaded dynamically through LoadLibrary api in some other openGL library. I am not very familiar with openGL binaries, so I cannot confirm this for you.
If you have problems to find where glut.lib is hidden in the visual studio project options, open the .vcproj in a standard text editor and make a full text search.