Fixed a problem. Help me understand why :)

[tescrin]

Alright, so I *finally* got all my ducks in a row on getting a plugin to work both in the Qt Designer and not give any linker errors on compilation etc..

My main issue was that I get receiving linker errors when I had built it as a DLL; the only way to solve those errors was to include the .h and .cpp files directly in with the project, but that's defeating the purpose of encapsulationl! So I went ahead and finally attempted to build the plugin as a *static* library. This replaced the old .lib file and it all works now! (It's worth noting that this was more than one class. The plugin class used another custom class. The dynamic library presumably wouldn't compile my other custom class in with the plugin class and gave me linker errors.)

I guess my question is:
-Why didn't the DLL compilation compile both classes into it's .lib file but the standard library compilation did?

I investigated the issue pretty thoroughly but I have not figured it out yet. It's worth noting that I have not built .lib type files in the past. Help understanding why this fixed my issue would be much appreciated.
Thanks!

[amleto]

what compiler are you using?

e.g. on microsoft you have to do something like __declspec(dllexport) and have some code in .cpp file for .lib file to be made. otherwise the library is "header only" and you must include the header and not dll/lib.

Essentially, you got linker error because you either:
- had nothing in the library to link with -> build/compile problem with the dll.
- did not properly configure your project to link with the correctly built library

[tescrin]

Hm, well, it does export the DLL file and additionally has an "Export library file" (exp) that goes with it. I didn't add code to any .cpp files to ensure the other class would be included other than standard #include statements.

Is there anything dirty about using the static library compared to a dll? Is there a reason I should go figure this out (other than being a learning experience) over just using the Static Library?

Thanks!

[amleto]

I didn't add code to any .cpp files to ensure the other class
__declspec would go in the header, not the .cpp.

yes. static library means any change to a library and you need to rebuild your whole app. With dll you just rebuild the dll.


You should show your dll code and how you were trying to link it.

[tescrin]

Attached is the full code (plus the vs2010 solution) mostly because I'm not sure I understand what you're asking for and your signature.

I linked using the following algorithm:
-I built this in VS2010 using the ".dll" project settings, set to output at <build_location>
-In a separate program I added the <build_location> to the included libraries and added the built library to it's additional dependencies (this is all under the VS "linker" tab. Right click the project name in the solution explorer->properties->configuration properties->linker)

From browsing online it looks like I just add:
__declspec(dllexport) in front of each class I wish to include in the dll? Is Visual Studio automatically doing this at all? It might be worth noting that the .dlls work fine with/for designer, they just don't actually link for the real program :s.

EDIT: Tried that. Same link issues.

[amleto]

Is Visual Studio automatically doing this at all?
No.

I will have a look at the solution...


... You forgot the project files.

[tescrin]

I assume you mean the VS Project files; I figured you wouldn't want them (because they'll change user settings and such.) Here ya go.

EDIT: If no, I'm not using a real .pro file. VS seems to abhor them as even when I write one correctly I have to go manually include paths and a bunch of other hoopla. I wouldn't be using VS if I didn't have to lol.

[amleto]

compile settings and linker settings are in the project file not the solution...

---

Added after 10 minutes:

you can see from using depends.exe that your dll is virtually empty - this will be because you are not exporting any of your classes into the dll (__declspec...).

[tescrin]

I hate to be dense; but does this mean you're looking for the project I was trying to link to as well? If so, it's really not necessary if you perform the above steps (add the library location, add the library as a dependency) as I'm just doing it with a simple generated project and adding this class using the designer on the provided form (to test it.)

Further, the paths probably won't like up with your pathing meaning it's probably more work to do it that way.

Either way, thanks thus far


EDIT:After your edit
With the modified code (just adding __declspec(dllexport) to the classes) the linker still gives me the same errors.
It's also worth noting that I only get errors regarding "textspinbox" (the class being used by the plugin) and not the plugin class itself (bertspinbox)

I'll keep looking into the declspec issue.., it looks like you have to import as well (on every function that uses dll stuff?)

[amleto]

yes, when you include the headers in the project that needs to link against the dll, it needs to be dllimport.

this 'problem' is normally solved with #defines.

#ifdef BUILD_THIS_DLL
  #define DECLSPEC __declspec(dllexport)
#else
  #define DECLSPEC __declspec(dllimport)
#endif

#ifdef BUILD_THIS_DLL
  #define DECLSPEC __declspec(dllexport)
#else
  #define DECLSPEC __declspec(dllimport)
#endif

To copy to clipboard, switch view to plain text mode 

where BUILD_THIS_DLL is only defined for the dll project and not the app using the dll.

See also http://msdn.microsoft.com/en-us/library/8fskxacy.aspx

[tescrin]

Thanks for the help. I'll have to go find a tut on doing this correctly as right now I'm just breaking my code :s. (it's generating multiple definitions for the same classes and such)