Problems with implementing dlls
Hello,
I know this is a simple question, but I'm really stuck here; I even bought a book and made what was written there, but it didn't help.
I wan't to use the library wavelet2d from here. I'm using Visual Studio 2008. The documentation tells me that the files:
wavelet2d.lib
wavelet2d.h
wavelet2d.dll
libfftw3-3.dll
are needed. So I copied them to the source folder of my program. Then I right clicked on my project in the project-explorer and chose add-> existing element and chose to add wavelet2d.lib.
I tried to include a folder where I copied the files as an additional includepath, but that changed nothing.
What is going wrong? Do I have to #include something in my program? The functions of the lib aren't found.
I'm sorry if the names of the buttons in VS2008 I used are wrong, I'm german and I just translated the words.
Thanks in advance!
Best regards,
Nikolas
Re: Problems with implementing dlls
What type of errors do have? Compiler erros? Linker errors? Run-time errors?
Re: Problems with implementing dlls
error C3861: "dwt_sym": identifier not found.
Best regards,
Nikolas
Re: Problems with implementing dlls
Quote:
Originally Posted by
Physikant
error C3861: "dwt_sym": identifier not found.
What is "dwt_sym"? Where is it declared? If it is the wavelet2d.h then you had to
Code:
#include "wavelet2d.h"
in the file rhat uses this identifier.
Re: Problems with implementing dlls
It is in wavelet2d.h. If I include that file, I get a linker error:
error LNK2001: unresolved external symbol ""void * __clrcall dwt_sym(class std::vector<double,class std::allocator<double> > &,int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::vector<double,class std::allocator<double> > &,class std::vector<double,class std::allocator<double> > &,class std::vector<int,class std::allocator<int> > &)" (?dwt_sym@@$$FYMPAXAAV?$vector@NV?$allocator@N@std@@@std@@HV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@00AAV?$vector@HV?$allocator@H@std@@@2@@Z)".
Thanks for the reply.
Best regards,
Nikolas
Re: Problems with implementing dlls
Good!
Now you have to add some libs containing these "unresolved external symbols". I presume there should be wavelet2d.lib library!
Re: Problems with implementing dlls
Try inserting
#pragma comment( lib, "wavelet2d")
at the top of the program. This will instruct the linker to load the wavelet2d.lib (looks first in the current working directory and then in the path specified in the LIB environment variable.)
Re: Problems with implementing dlls
I inserted the line at the beginnig of my code and I added wavelet2d.lib in the project-explorer as a ressource-file and in the main root of the project.
Still the external symbol can't be resolved.
Best regards,
Nikolas
Re: Problems with implementing dlls
Quote:
Originally Posted by
Physikant
I inserted the line at the beginnig of my code and I added wavelet2d.lib in the project-explorer as a ressource-file and in the main root of the project.
You should not do it. This .lib file has nothing to do with the resources.
You have to insert the file into project folder (note that I mean Windows Explorer folder, not a VS "project-explorer"!)
Re: Problems with implementing dlls
I removed the lib from the ressources folder again, but its still in the list of the project.
The lib-file is in the folder of my source on the hdd.
Any more ideas? :(
Best regards,
Nikolas Becker
Re: Problems with implementing dlls
Quote:
Originally Posted by
Physikant
I removed the lib from the ressources folder again, but its still in the list of the project.
The lib-file is in the folder of my source on the hdd.
Any more ideas? :(
Perhaps "the folder of your source on the hdd" is not "the current working directory"?
Re: Problems with implementing dlls
I've checked wavelet2d.lib and dwt_sym is defined there as an export. So there must be somethig wrong with how you are telling the linker to find/use wavelet2d.lib. Try putting the full path name to wavelet2d.lib in the #pragma statement - or add it to the linker additional dependencies property field for the project in MSVS.
Re: Problems with implementing dlls
Ok, I came back to this project and it's still not working.
I made a test project from scratch to make sure there is no problem with what ive done so far.
My project has this structure:
[1]wavelet2test
[2]wavelet2test\Debug
[3]wavelet2test\Release
[4]wavelet2test\wavelet2test
[5]wavelet2test\wavelet2test\Debug
[6]wavelet2test\wavelet2test\Release
What ive done:
In the download, there are two folders, Release and Debug. I copied the wavelet2d.dll and wavelet2d.lib from Debug to [2] and [5], and from the Release folder to [3] and [6]. Then I copied the libfftw3-3.dll from another directory of the download to [2],[5],[3] and [6].
Then I copied wavelet2d.h from the src-folder of the download to [1] and [4].
In the project-explorer, I added the wavelet2d.lib I copied to [2] as an element to the wavelet2test-project.
I added #include "wavelt2d.h" as the first line to my program.
I added [2],[3],[5],[6] to the directories for the linker.
In the program, I call dwt_sym (I think it has no namespace). If I do that, I get the two previously discussed linker errors LNK2028 and LNK2019.
If I add #pragma comment( lib, "wavelet2d") to the first lines of my code, I get many warnings in addition to the two linker errors (here is one of them, they are all similar):
warning C4272: "dwt_sym": is marked __declspec(dllimport); must specify native calling convention when importing a function.
Any ideas what i could try?
Thanks so far!
Best regards,
Nikolas
Re: Problems with implementing dlls
1. You did not mention "linker errors LNK2028 and LNK2019".
2. You neither added the wavelet2d.lib in the linker additional dependencies property field nor did you set the full path name to wavelet2d.lib in the #pragma statement. So you have just ignored what 2kaud suggested you in his latest post.
:sick:
Re: Problems with implementing dlls
Quote:
Originally Posted by
Physikant
It is in wavelet2d.h. If I include that file, I get a linker error:
error LNK2001: unresolved external symbol ""void * __clrcall dwt_sym(class std::vector<double,class std::allocator<double> > &,int,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::vector<double,class std::allocator<double> > &,class std::vector<double,class std::allocator<double> > &,class std::vector<int,class std::allocator<int> > &)" (?dwt_sym@@$$FYMPAXAAV?$vector@NV?$allocator@N@std@@@std@@HV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@2@00AAV?$vector@HV?$allocator@H@std@@@2@@Z)".
Where to start...
First, I can't fathom why anyone would create a library that passes STL and/or C++ classes between DLL and application like this. You now have to verify that you're using the same compiler, compiler version (right down to the same service pack), compiler options, etc. to ensure that the link will work. This has been discussed on many threads here, with the bottom line being that a library shouldn't pass STL or any C++ objects across DLL/exe boundaries like this.
Unless you have complete documentation on the exact build options for your application (and you're using the same compiler), then you're going to get into more trouble trying to use this library.
I looked at the dll file using dependency walker. That function that is attempting to be resolved does not exist in that DLL. What exists in that DLL is exactly why my first point is relevant:
Code:
?dwt_sym@@YAPAXAAV...
See the difference? What you compiled and linked doesn't match the name that's in the DLL. The name is mangled differently in the DLL, meaning that the DLL was built differently. Add to that, the author may have used the _SECURE_SCL=0 macro (which optimizes the STL iterator logic in release versions). If they did and you didn't use that macro (or vice-versa), then at runtime, things will come crashing down.
This is the price that is paid when C++ objects and types are passed as parameters instead of standard types such as LONG, LPCTSTR, etc. You now have to basically have the entire set of the compile options you need to set before building your application.
Regards,
Paul McKenzie