CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 28 of 28
  1. #16
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Problems with implementing dlls

    Quote Originally Posted by VictorN View Post
    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.
    I think it's worse than that. Just the mere fact that the library is using C++ types as parameters ensures that something will go wrong somewhere.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; July 26th, 2013 at 11:49 AM.

  2. #17
    Join Date
    Jun 2013
    Posts
    12

    Re: Problems with implementing dlls

    @VictorN
    I already added it to the additional dependencies for the linker, thats what i meant with the sentence "I added [2],[3],[5],[6] to the directories for the linker.". Sorry, I always have to translate this english terms to german, what makes it sometimes difficult to know if I found the right option.
    I added the full path name, if I do it correctly, the two linker errors from my previous post appear again.

    @Paul McKenzie
    Thank you for the information. TBH, I don't really get whats the exact problem here. If I get this right, the author of the library made some terrible descisions which make it impossible for me to use this lib. So the best advice would be taking the source and trying to implement the whole library directly in my project (don't I violate some licenses by doing so?)?

    Thanks!

    Nikolas

  3. #18
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: Problems with implementing dlls

    Quote Originally Posted by Physikant View Post
    Sorry, I always have to translate this english terms to german, what makes it sometimes difficult to know if I found the right option.
    I agree.
    My first expirience to work with the German version of VC++ 6.0 in 2000 let me move to the native (not for me but for VC++ 6.0 itself) English one. And after that I never ever tried to use some other than English VS language version (nor the Russian one despite Russian is my native language!)
    Victor Nijegorodov

  4. #19
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Problems with implementing dlls

    Quote Originally Posted by Physikant View Post
    @Paul McKenzie
    Thank you for the information. TBH, I don't really get whats the exact problem here.
    The problem as I see it is very simple.

    When you create a C++ function, the C++ compiler needs to create a unique "stub" for this function so that the linker can resolve these functions. The issue with C++ is that functions can be overloaded, i.e. given the same name, but the parameters are different. So to make sure the linker sees two distinct functions, the C++ compiler intentionally mangles the name. The way the name is mangled is compiler dependent, but further compiler options can affect how a name is mangled.

    Now the C++ compiler mangled the name, and now gives this name to the linker. The linker knows absolutely nothing about mangled names, non-mangled names, or even C++. All the linker knows is that it has a name, and is trying to match it with the names in the library you have. The name the linker is matching is not just "dwt_sym", as would suggest. It is that entire string you see there -- yes, including all of the @ characters, question marks, etc. To the linker, that is the function name, not "dwt_sym".

    So that's why you get the error -- it is indeed the fact that the linker can't find that name in the DLL. Nothing more, nothing less.
    If I get this right, the author of the library made some terrible descisions which make it impossible for me to use this lib.
    It is a good decision only if the author has laid out exactly how you are to set up your project to use the DLL, i.e. compiler options, preprocessor constants to set or unset, CRT to use, and most important, what compiler and version you must use. Contrast that to a DLL that has functions that do not use C++ types directly as parameters, and you then have much more flexibility. The issue though is that the library would have to be redesigned in a way so that these limitations are greatly reduced or even eliminated altogether.
    So the best advice would be taking the source and trying to implement the whole library directly in my project (don't I violate some licenses by doing so?)?
    I don't think so if you are given the full source code. At this point, that may be the best thing to do, with the alternative being that you rebuild the DLL yourself using options that you are well aware of that can be copied to your EXE project.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; July 26th, 2013 at 12:50 PM.

  5. #20
    Join Date
    Jun 2013
    Posts
    12

    Re: Problems with implementing dlls

    So I put the parts of the library I need directly in my code. And there is the next problem: it uses libfftw3-3.dll.
    On the homepage of libfftw3-3.dll (here, i found the dll, the header file and a .def file, together with the advice to use lib.exe /def:libfftw3-3.def to create a lib file. I did this and it brought me a .lib and a .exp-file. I copied them together with the .h and the .dll to to directory where the .h and the .cpp files of my program are. Then I added the .lib to my project. If I compile now, I get 3 errors for every call of a fuction from libfftw3-3.dll:
    LNK2031(unable to generate p/invoke for "function_declaration" decorated_name; calling convention missing in metadata), LNK2028("exported_function" (decorated_name) referenced in function "function_containing_function_call" (decorated_name) ) and LNK2019(unresolved external symbol 'symbol' referenced in function 'function' ).
    I think it wouldn't be that easy to copy the needed parts of libfftw3-3.dll from the source than it was from the parts of the wavelet2d.dll.
    Sorry that this is so annoying

    Nikolas

  6. #21
    Join Date
    Jun 2013
    Posts
    12

    Re: Problems with implementing dlls

    A while i thought that I solved it, but I just made the error to put the .dll to the additional dependencies instead of the .lib. If I put the .lib there instead, I get 2031, 2028 and 2019 again.
    *sigh*
    Last edited by Physikant; July 26th, 2013 at 05:51 PM.

  7. #22
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,675

    Re: Problems with implementing dlls

    Quote Originally Posted by Physikant View Post
    LNK2031(unable to generate p/invoke for "function_declaration" decorated_name; calling convention missing in metadata), LNK2028("exported_function" (decorated_name) referenced in function "function_containing_function_call" (decorated_name) ) and LNK2019(unresolved external symbol 'symbol' referenced in function 'function' ).
    Looks like you're trying to use a native library in a managed (i.e. .NET) project. Probably C++/CLI, since all that confusion we see now would have been unlikely to arise in the first place if it were C# or even VB .NET.

    Things like that can become really, really complicated, even when things like exporting C++ types from a native library (which isn't really recommended even in a purely native project) aren't involved at all.

    This is rather advanced stuff that shouldn't really be done by people who don't know what they're doing - and not realizing at all that it's about a combination of managed and native stuff is a half-way certain indication of not really knowing what's going on.

    I don't mean to say we're not going to help you because this is way over your head, but be prepared for a steep path to go...
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  8. #23
    Join Date
    Jun 2013
    Posts
    12

    Re: Problems with implementing dlls

    The only functions calling libfftw are from the wavelet lib, which is in native c++, not managed. So it uses these data types, mainly vector. As I said, I copied the parts of the code form the wavelet lib to my main code and didn't change the data types.
    What really bothers me is that the FFTW homepage suggests using it with VC++ and how this can be done, and it's still not working.
    Anyway, I'm willing to learn and spend some time with it, so if someone would help me here, I really would be happy
    Nikolas

  9. #24
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,675

    Re: Problems with implementing dlls

    In that case I'd suspect that you unintentionally activated CLR support for at least one of your source files. So I'd suggest you carefully check your project settings for that; not just the general settings, but also those for the individual .cpp files. I can't imagine how the LNK2031 error could arise without at least one managed module being involved.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  10. #25
    Join Date
    Jun 2013
    Posts
    12

    Re: Problems with implementing dlls

    Oh, one of my source files uses managed code! Basically, i've got a gui with the .net librarys. I call from this code a function of the wavelet library. This function (and all that are needed for the function) is in a seperate file, and this one only uses c++ native (and my managed code only calls the function with c++ native variables). This function now calls libfftw. So thats why i've got problems? That a part of my program uses managed code, although the function using the lib only uses native stuff?
    And if yes, is there any workaround except trying to implement the needed libfftw-parts directly in my program from the source (which sounds really ugly) ?

  11. #26
    Join Date
    Jun 2010
    Location
    Germany
    Posts
    2,675

    Re: Problems with implementing dlls

    Ok, then first change the CLR support option of all your managed modules to /clr if it currently is /clr:pure, which is the default for an IDE-created Windows Forms project (at least in the 2010 version). IMO the pure part of the option is rather counter-productive in a mixed-code project anyway and removing it may instantly fix your LNK2031 issue, since that changes the default calling convention assumed for free functions in the managed modules from __clrcall to __cdecl.

    If that doesn't help you may try explicitly specifying the calling convention __cdecl in the offending function's declaration, as described in the linker error's MSDN documentation. However, that probably would require changing the 3rd-party librarie's .h file(s), so you may want to avoid it.

    The above suggestions are meant to fix the LNK2031 error, yet there still may be other problems you'll need to solve. Unless you're exclusively calling extern "C" __cdecl functions (with appropriate parameter types) across DLL boundaries, that may well be the issues already discussed in this thread. Or it may be completely new issues that have been obscured by others so far. At any rate, getting rid of the LNK2031 will take you a significant step forward.
    I was thrown out of college for cheating on the metaphysics exam; I looked into the soul of the boy sitting next to me.

    This is a snakeskin jacket! And for me it's a symbol of my individuality, and my belief... in personal freedom.

  12. #27
    Join Date
    Apr 1999
    Posts
    27,449

    Re: Problems with implementing dlls

    Quote Originally Posted by Physikant View Post
    I'm willing to learn and spend some time with it, so if someone would help me here, I really would be happy
    Nikolas
    What you should do is to start from scratch.

    Create a brand new, non-managed C++ project, and then attempt to use the library using a very small main() program by calling a couple of the functions. The functions need not even make sense in the manner or paramters used -- the goal is to create a program that compiles and links successfully. Nothing more than that.

    Then when you run it, all you need is to see if the main() program starts without error (no DLL not found issues). And that's it. Then you move onwards with the larger project, with the knowledge of knowing how to set things up correctly.

    That is the way you learn how to properly use DLL's, and also diagnose any problems. Also doing things this way aids in you learning why things work or don't work with respect to lib files, DLL's, etc..

    Otherwise, you'll be fighting with this much larger project with very little to no hope of actually getting things done. Once you have the smaller project working, then and only then would you apply the same steps to the larger project.

    Regards,

    Paul McKenzie
    Last edited by Paul McKenzie; July 27th, 2013 at 03:44 PM.

  13. #28
    Join Date
    Jun 2013
    Posts
    12

    Re: Problems with implementing dlls

    Hello,

    i've did it
    The suggestion of Eri523 solved the problem.
    Thanks to everyone who spent his time to help me.

    Best regards,
    Nikolas

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured