[MSVC 2010] Static linking and unresolved external symbols

[Blood9999]

I don't have any *.pro file. Visual Studio 2010 doesn't create any one. I thought about create one, but i have no idea how to attach it to project.

But my main problem and reason why i need static linking. I have to use QAxWidget in my project, but as far as i know i have to do static build to be able to include ActiveQt to my project. Am i right?

EDIT

Hmm ... i think that i found something. Is it true that i can't build project just using Visual Studio, but i have to use qmake and then nmake?

[d_stranz]

I build all of my projects using the Qt Add-in for Visual Studio. You don't need to use qmake or nmake - it is all done within VS using the toolbar / menu commands to build projects.

Use the Qt Add-in to add a new Qt GUI project and select QWidget as the class to use as the base of the GUI. If you've tried to build a new project manually, you have most likely have a project where some required libraries are not being included in the link. Using the Add-in avoids this problem.

You do not need a static Qt build in order to use ActiveQt. It works just fine in the default DLL version. I don't know where you got that crazy idea. Nothing in Qt requires a static build, and in fact static libraries are incompatible with the LGPL license under which Qt is released.

[amleto]

...
and in fact static libraries are incompatible with the LGPL license under which Qt is released.

No they're not.

[Blood9999]

You do not need a static Qt build in order to use ActiveQt. It works just fine in the default DLL version. I don't know where you got that crazy idea. Nothing in Qt requires a static build, and in fact static libraries are incompatible with the LGPL license under which Qt is released.

Then show me where have you got any kind of ActiveX DLL file

[amleto]

those PARTICULAR libraries may be static libs, but that does not mean the whole of your Qt build has to be static...

[Blood9999]

As far as i know, you can't build your application half static and half shared ;D

[amleto]

wow, you still don't get it?

You can link against static and shared libs. You do not need a static Qt build to use the qt activex sttic libs.

capisce?

[d_stranz]

No they're not.

LGPL requires that you be able to substitute the functionality contained in a library at run time by substituting another library with the same functionality (and function signatures), unless you provide the source code for the library in question (see clause 4.d). So either you have to make available the source code to the Qt libraries you have statically linked against, or you have to link dynamically.

You can link against static and shared libs. You do not need a static Qt build to use the qt activex sttic libs.

I think you would likely run into problems trying to compile the application. You have to declare the compile-time constants (QT_DLL, etc.) that tell the compiler how to bring in the class and methods declarations from the Qt header files. If you are using part of Qt that has been compiled statically and part that has been compiled into DLLs, the function signatures for any dependencies between the libraries are probably going to be inconsistent with one definition or the other. This isn't to say it can't be done, but you probably couldn't do it as a project-level declaration - it would have to be done on a header-by-header basis where you have to modify the QT_DLL define as appropriate for each source and header file (and all their dependencies). I think it would be a real mess.

Then show me where have you got any kind of ActiveX DLL file

You know, I think you are right - the vcproj files for QAxContainer.lib and QAxServer.lib build them both as static libraries, not DLLs. (As does the .pro file: CONFIG += qt warn_off staticlib)

The header files for the ActiveQt classes declare them without qualifiers (e.g. class QAxBase), whereas the headers for the core Qt classes it uses are declared with the export macro (e.g. class Q_CORE_EXPORT QObject), which I guess does the right magic to ensure that the declarations are consistent when link time comes.

[amleto]

LGPL requires that you be able to substitute the functionality contained in a library at run time by substituting another library with the same functionality (and function signatures), unless you provide the source code for the library in question (see clause 4.d). So either you have to make available the source code to the Qt libraries you have statically linked against, or you have to link dynamically.

Exactly. Static libraries can be used and can comply with LGPL.

As for the issue of qt/ActiveQt, it is all explained in the docs http://doc.qt.io/qt-4.8/activeqt so there is no static/shared problem here either. Not to mention your edit that says that dll import macros wont get in the way of statically linking against those libs when you need to also link against the rest of your non-static Qt build

[mingxin505]

imm32.lib
winmm.lib
Ws2_32.lib
add these librarys to Project

[d_stranz]

I am sure that after almost 2 1/2 years, everyone is excited and happy to finally get this answer.