Tons of unresolved externals when building a dll and statically built Qt 4.7.0

[wysota]

Did you run it before or after you added the Q_OBJECT macro to your class?

[kvb]

The QObject Macro was added before I ran qmake. Does it make a difference?

[wysota]

Did you remove the dynamic version of Qt before building the static one?

[kvb]

I guess I can't be certain that I did. How do you remove the dynamic libs? Is there any easy way to do it now that I've built the static libs?

[wysota]

You delete them or build the static version in a different directory. Otherwise your projects might pick up the dynamic libraries instead of the static ones.

[kvb]

I guess I was under the impression that the static build would be built in a different directory than the dynamic libraries. Could you point me at the dynamic libs? I'm not even sure where the static libs were put...I didn't pay too much attention to the paths during the build unfortunately.

[wysota]

Then it will probably be a good lesson for you to try and find the libraries yourself. You'll learn something about Qt's directory layout.

[kvb]

yeah okay, so in the root there is a bin directory with dll's in them and it looks like the static libs are in the lib/ directory. So they are in different directories.

[wysota]

dll files are not used during the compilation. The lib files are. Now imagine you have a mix of lib files from a static and dynamic build, draw the conclusions yourself

By the way, I fail to see a practical use of a Qt-based dll compiled with static Qt libs. Would you enlighten me about your ultimate goal?

[kvb]

In looking at the lib files, it looks like they all have modified dates of around the 2 hrs or so when I was building the static libs so I doubt that there is a mix.

The idea for the Qt-based dll is to have to reduce the number of dlls that I have to distribute to co-workers. I created a dll that does some image manipulation that interfaces to some scripts I have written in Ruby. Qt was used because the image processing is much faster in Qt than in other ruby libs that we could find. Maybe it's simpler if I just distribute the QtCore4.dll (and any other dlls needed) with my custom dll. I was hoping to only have to distribute only one file (and by distribute I mean check in to the project on svn). Not everyone has Qt installed on their machine so that is another reason I was hoping to use a static build.

[wysota]

I don't know what you intend to do later but so far you are exposing Qt interface to the outside world so programs that want to use your library would have to link against Qt as well. There are ruby bindings for Qt (or is it Qt bindings for Ruby? Whatever...) available, maybe that will be a more suitable solution for you - you wouldn't have to touch any C++ code at all.

[kvb]

Well it turns out that adding the line DEFINES += QT_NODLL to my .pro file got rid of all my issues...I swear I tried that before and it didn't work.

exposing Qt interface to the outside world so programs that want to use your library would have to link against Qt as well

I'm afraid I don't understand this statement, isn't the purpose of doing the static build suppose to get you away from having to link against qt in other applications? Maybe I'm just too confused to be helped...

I will look into the ruby bindings, they could be really usefull. Thanks for pointing those out!