Lets Dialog with Qt

[qtoptus]

More details:

extern "C" void plugin_starter(...)
{
//Qt-main-code copied here

// Instantiate dialog class, CRASH!

}

[qtoptus]

Finally this worked! I have the dialog shows within the main program and no problem. After I added a tabbed widget to the dialog, the plugin fails to load again. And I got this message:

msg2.jpg

I have the correct DLLs QtCore4.dll, QtGui4.dll QtOpenGL4.dll version 4.8.2 and all copied from Qt\4.8.2\bin\

Any idea?

[qtoptus]

Any suggestions?

I'm suspecting it's a problem with Qt build itself since the module is aware of the dependency DLL, QtGui4.dll, but it cannot link to the function, which means a different signature/name mangling...

Should I build Qt from the source?

Can I link to static version of Qt libs?

[amleto]

do you have qt built with the same compiler as your app?

[qtoptus]

I installed the binary version 4.8.2 for the same compiler VS 2008.

[amleto]

how do you build your app, how do you link it with qt?

you will not be able to statically link since you have not built static qt libraries.

and you say you use sdk 4.8.1 earlier in the thread, but now you have installed 4.8.2 binaries? They should be compatible anyway, if built with same compiler.

[qtoptus]

I use VS 2008 and the Qt VS add in latest version. So I create a Qt library, using the Qt Project Wizard, and then add a Dialog box control to the project.

Yeah I decided later to update thinking of this might solve the problem.

[amleto]

'qt libraries' are qtcore4.dll etc. You do not create those from qt project wizard. You either install those, or build them from source.

What you are doing is building qt 'derivative' works/libraries, I believe.

[qtoptus]

I have the Qt SDK installed so I'm using the the Qt dlls from the Qt\4.8.2\bin directory. HOWEVER, now I'm suspicious that the VS Add-in wizard is linking to the wrong version using it's own DLL static link libraries Qt LIBs, while I'm using the installed SDK version.

Another possibility that VS is screwing the hell of the build. I run windows 7 64 bit, the called application (Lightwave 3D) is 32 bit, the VS 2008 is 32 bit, and not sure what bits Qt is built for...

I will try rebuilding from source and using static linking instead, as the entire DLL thingy smells fishy to me...

[amleto]

I have the Qt SDK installed so I'm using the the Qt dlls from the Qt\4.8.2\bin directory. HOWEVER, now I'm suspicious that the VS Add-in wizard is linking to the wrong version using it's own DLL static link libraries Qt LIBs, while I'm using the installed SDK version.

Another possibility that VS is screwing the hell of the build. I run windows 7 64 bit, the called application (Lightwave 3D) is 32 bit, the VS 2008 is 32 bit, and not sure what bits Qt is built for...

I will try rebuilding from source and using static linking instead, as the entire DLL thingy smells fishy to me...

You haven't build static libraries so how can the addin link to any static library?
The addin doesn't have its own libraries so how can the addin do that?
What on earth is a 'dll static link libraries Qt LIBS'?

That whole second sentence is gibberish.

the Qt installed libraries and the libraries that are made when compiling from source are 32bit. Even if you build with a 64bit compiler, they are 32bit. There are no 64bit qt libraries afaik.

[qtoptus]

I tried this time linking to Qt static libraries, built from the source. It failed to build. A hell of unresolved external symbols.

What on earth is a 'dll static link libraries Qt LIBS'?

Read, or google.

That whole second sentence is gibberish.

I've no idea what you are talking about.

Anyway it seems that I'm wasting time trying to do something supposed to be trivial but "something" there is broken.

[wysota]

Read, or google.

I also have no idea what this sentence means since DLL resolves to "Dynamic-Link Library" so mixing DLL and "static" in once sentence is a bit like talking about a round square.

If you want to have a static build, then you need:
a) a static version of every library you want to use (including Qt)
b) a static C/C++ runtime (optionally, I think)
c) link your application against a) and b) statically.

If you don't follow this approach then the only thing that is "broken" is your way of trying to solve the problem which is indeed trivial and is well documented both in Qt manual and all over the Internet. Of course you need to be familiar with all the caveats and pitfalls of static and dynamic libraries and mixing them together including the way symbols are getting resolved or not (which probably heavily depends on the compiler you are using). If you do not have such knowledge and are not willing to learn it then the best solution is to rely on the defaults, which in this situation is dynamic linking of everything everywhere and dumping required libraries to a well-known place where the system's dynamic linker can find them when resolving symbols for your shared objects.

[amleto]

I tried this time linking to Qt static libraries, built from the source. It failed to build. A hell of unresolved external symbols.

Read, or google.

I've no idea what you are talking about.

Anyway it seems that I'm wasting time trying to do something supposed to be trivial but "something" there is broken.

1) I still don't believe that you have any static qt libraries to link against.
2) I think you need to learn what some of the phrases you are using actually mean.

For instance - 'statically linking a dll' - that is gibberish. Linking with a dll does not incorporate that dll code into your app/library so it is not statically linked.