Explain Qt library sizes, please

[bnilsson]

Why are the (static) Qt debug libraries smaller than the (static) release libraries?
E.g. qtmain.lib is 1019kb while qtmaind.lib is 64kb?
The trend is consistent for all libs, it seems.
I would expect the opposite?

Platform: win32-msvc2008
configure -debug-and-release -static -no-webkit
nmake sub-src

[wysota]

Your qtmaind.lib is surely a dynamic export library not a static library.

[bnilsson]

So my

configure -debug-and-release -static -no-webkit
nmake sub-src

configure -debug-and-release -static -no-webkit
nmake sub-src

To copy to clipboard, switch view to plain text mode 

did not do what I thought it would do?
The .lib files are fresh from the build date, and as described in Assistant they are not named "*4.lib" or "*4d.lib", correct for a static build.
And back to the original question, should there not be symbolic information in a debug library which is not present in a release library, thus making it (the debug library) bigger?
My QtGui.lib is 211483kB and the QtGuid.lib is 70340kB. Since the debug libraries obviously works, what is the extra content in the release?

[wysota]

Does it really matter?

[bnilsson]

Why do you ask?

I am trying to troubleshoot my installation, and I am not ready to give a complete description of my problems just yet.

[bnilsson]

Some libraries I've built for my own app also have larger release size then debug size, and I am not sure if I have by mistake swapped the targets. At deployment, the release libs should be linked to the app and not the debug libs.
I am using the qt-vs addin, giving me LOTS of such problems, bugs are reported.
On Mac, the debug libs are (I assume) containing more data than the release libs, that's why I am confused by what I see in win32-msvc2008.

[bnilsson]

More details about why I am interested:
I tried to make a "release" app to run on another PC, but the app failed to start on the other PC.
It needed VC90.CRT, which I installed using redist_x86.exe (or similar, dont' remember the name now).
It still would not start, it needed VC90.DebugCRT, which is not redistributable according to Microsoft.
This is why I suspect I have inconsistent debug/release app configuration, maybe linked to debug libraries when it should be release libraries.

[wysota]

Ok, but why are you interested in the size of a static debug library? Give me one example where it makes sense to use a static debug library.

[bnilsson]

Ok, I will try to explain very very carefully so you can understand.

If my project, for any reason, in the "release" configuration, instead of linking to a "release" library, which is my intention, links my app to a "debug" library, it will PROBABLY have a dependency to Windows "debug" environment, which is not available outside the PC which is created. Thus the deployed app will not work on any other PC than the one where it was created.
My app is dependent on a library which is is made by me, and this library project produces both debug and release versions. If there is a unintentional swap between the debug and release versions of these libraries, I will link to the wrong version and my app will not run. I have reason to believe that the qt-vs-addin I am using is not stable and might screw up the output destinations, names and whatnot.
One crude and primitive way of determining which is debug and which is the release version that actually are created could be by the size, since I expected the debug version would be larger. It seems to me this is not the case for Qt libraries, so I will have to skip this idea.

Why would I want to use a static debug library? I do not.
I want to make a static linked app to reduce the work in deployment, as described in Assistant. The project to create it will be static accordingly, and since I am a poor enough programmer to want to debug it to make it work, the debug configuration will use a static debug library.

Since you do not seem to have an answer to my original question (or don't want to answer) I suggest we end this now.

[wysota]

If my project, for any reason, in the "release" configuration, instead of linking to a "release" library, which is my intention, links my app to a "debug" library, it will PROBABLY have a dependency to Windows "debug" environment, which is not available outside the PC which is created. Thus the deployed app will not work on any other PC than the one where it was created.

So link it to the proper one... Where is the problem?

One crude and primitive way of determining which is debug and which is the release version that actually are created could be by the size, since I expected the debug version would be larger. It seems to me this is not the case for Qt libraries, so I will have to skip this idea.

The simplest way is to use dependency walker and see what libraries do each of them depend on.

Why would I want to use a static debug library? I do not.
I want to make a static linked app to reduce the work in deployment, as described in Assistant.

By building in debug_and_release?

The project to create it will be static accordingly, and since I am a poor enough programmer to want to debug it to make it work, the debug configuration will use a static debug library.

While developing you should use dynamic libraries, unless you are paid by the hour and hard-disk space taken by the project. Statics should be used only for deployment.

Since you do not seem to have an answer to my original question (or don't want to answer) I suggest we end this now.

That's because your question is irrelevent to your problem. The size of the library can depend on the libraries that are linked into this library. If you link statically, you are embedding all the dependant static libraries available which is boosting the size of each library. If you want to compare release and debug library sizes (although I don't know why would you want to do that as it is meaningless - from what can be read in another thread Visual Studio saves its debug information into a separate file, so it doesn't boost the size of debug libraries), do it in dynamic mode where only the size of the library itself matters. Now you are comparing the libraries as you'd been comparing which car is better based on their weight because a better car will have more features so it will probably be heavier. It might be better to actually look into specs of both cars, don't you think? That's what dependency walker is for.

[bnilsson]

Thanks for the explanation.
I now see what my problem REALLY is.
I did not understand how a .pro file works regarding the debug and release configs.
I tried to do like this:

win32: TEMPLATE = vcapp
CONFIG 		+= debug_and_release qt thread 
release {
	DESTDIR = Release
	INCLUDEPATH += GeneratedFiles GeneratedFiles/Release .
	MOC_DIR = GeneratedFiles/Release
	OBJECTS_DIR = Release/obj
}
debug {
	DESTDIR = Debug
	INCLUDEPATH += GeneratedFiles GeneratedFiles/Debug .
	MOC_DIR = GeneratedFiles/Debug
	OBJECTS_DIR = Debug/obj
}

win32: TEMPLATE = vcapp
CONFIG 		+= debug_and_release qt thread 
release {
	DESTDIR = Release
	INCLUDEPATH += GeneratedFiles GeneratedFiles/Release .
	MOC_DIR = GeneratedFiles/Release
	OBJECTS_DIR = Release/obj
}
debug {
	DESTDIR = Debug
	INCLUDEPATH += GeneratedFiles GeneratedFiles/Debug .
	MOC_DIR = GeneratedFiles/Debug
	OBJECTS_DIR = Debug/obj
}

To copy to clipboard, switch view to plain text mode 

not understanding the the scope variables debug and release are BOTH defined when debug_and_release is used.
I assumed that the conditionals would set up my VC release/debug project configurations accordingly, and this did not work. Now as the debug scope was handled after the release scope, the debug scope wins.

Does the debug and release scopes in the .pro file have anything whatsoever to do with the generated VC project debug/release configurations?

If they do, can you suggest a method to achieve what I want to do (if I can make myself understood)?

[wysota]

Use the following construct:
"CONFIG(debug, debug|release) { ... }" for debug mode compilation and "CONFIG(release, debug|release){...}" for release mode compilation. Then when the compilation is in debug and release proper scopes will get activated.

[bnilsson]

Thanks, this seems to work on win32-mcvc2008.
However this does not seems to work on MacX, only GeneratedFiles/Debug is generated.
But this is not serious for me at the moment.

And still, the Win32 app wants VC90.DebugCRT to run on the other PC.
I have removed my linked-in library and put the source directly in the project, so there cannot be any debug/release mixup, if there ever was.
Any suggestions where I should look?
I have used the dependency walker and I have not found anything debug-related so far.

[wysota]

Thanks, this seems to work on win32-mcvc2008.
However this does not seems to work on MacX, only GeneratedFiles/Debug is generated.
But this is not serious for me at the moment.

It should work. Provided that debug_and_release is supported on Mac.

I have used the dependency walker and I have not found anything debug-related so far.

Did it show a dependency on the debug version of the C runtime? What exactly depended on it?

[bnilsson]

I tried again on another development PC, installed Qt like this in the VC2008 command window:

configure -static -release - no-webkit
nmake sub-src

So no static debug libraries were built.

Now I could build the release app and it finally worked at the target PC.
So far so good.

However, I failed to make the (same) VC project build a debug shared app, since the settings in the VC debug configuration was not properly set for this.
I had previously built Qt shared in the development PC so the shared libs were there also.
Is it possible to have a single VC project with both shared(debug) and static(release) builds?

And if it is, is it possible to have this generated by a single .pro file by qmake (with TARGET vcapp)?


In general, how does one usually set up the Qt/vc environment for shared debugging and static deployment?

[bnilsson]

As this discussion drifted a bit since the original question, I move the shared debug / static release build to another thread.