How do I change the Runtime Library setting in my project in QtCreator?

chadw · 6 Jun 2018, 09:12

Windows 7, QT 5.9.2 MSVC2017 64-bit, Qt installed from binaries (did not build from source).

At the moment, the debug version of my main project is set to "Multi-Threaded DLL (/MDd)" but this generates some errors because the linked processing library settings mean mismatch(es) are detected by the linker, for each class of the linked processing library. The error looks like this:

Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in imageprocessorhandler.obj Test C:\Users...\Documents\QT Projects\ProcessingLibTest\ProcessingLib.lib(imageprocessor.obj)

I can resolve[1] these errors when I build the project in Visual Studio, by going into Project Properties -> Configuration Properties -> C/C++ -> Code Generation, changing Runtime Library from the /MDd option to the /MD option and rebuilding the project.

I thought I came across a post helping me with this: https://forum.qt.io/topic/38042/building-standalone-qt-application/6

Namely, the Cflags option given in one of the answers in the above link:

QMAKE_CFLAGS_RELEASE += /MD

But modified to affect the debug settings? I.e.

QMAKE_CFLAGS_DEBUG += /MD

However, even changing the above _DEBUG setting in both the projects' respective .pro files (to match one another) has no impact. The linker errors remain.

Could anyone tell me where I'm going wrong here please?

[1] Maybe not the best solution, as running the debug version throws a different error...

THinking it over, it's should probably be /MTd, but if I set both the projects to /MTd, I get these errors for each class in the link project:

Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MTd_StaticDebug' in imageprocessorhandler.obj ...

And, an even larger number of "already defined in ..." linker errors of this fashion:

Error LNK2005 "public: __cdecl std::_Lockit::_Lockit(int)" (??0_Lockit@std@@QEAA@H@Z) already defined in libcpmtd0.lib(xlock.obj) C:\Users...\QT Projects\hexitec\ProcessingLibTest\msvcprt.lib(MSVCP140.dll)

chadw · 6 Jul 2018, 12:49

@JonB Thank you for persevering with me - I finally managed to figure it out. I was using the wrong variable in the end. It should be:

QMAKE_CXXFLAGS_DEBUG

With this in place, i.e. for instance changing it with:

QMAKE_CXXFLAGS_DEBUG += /MDd

I was being told that my new setting was being overridden:

But courtesy of the pointer of a SO post, I went into my Makefile.Debug file and hacked the relevant line as suggested by:

https://stackoverflow.com/a/25317701/2903608

Although now, QtCreator appear to honour whatever I set using QMAKE_CXXFLAGS_DEBUG, without needing to hack the makefile to avoid my setting being overwritten.

For clarity, it's the CXXFLAGS line in the Makefile.Debug that I initially (but no longer..) needed to modify.

JonB · 6 Jun 2018, 08:46

@chadw
I don't understand: are you building Qt libraries from source yourself too, or are you just building your own project(s) and linking against pre-built Qt libraries? Do the linker errors refer only to your own functions, or to those in Qt libraries?

jsulm · 6 Jun 2018, 09:39

@chadw Did you try to build in debug mode?

chadw · wrote on 6 Jun 2018, 09:37

Apologies for being vague - I did not build from source (just edited original post to clarify that). I installed the binary downloaded from Qt.

There are two libraries (inherited from a colleague). ProcessingLib processes pixel data, the second project (ProcessingLibTest) is a basic Gui allowing the user to select some processing options, file(s) to be processed, where to save processed files etc.

Running ProcessingLibTest.exe built as Release works fine. I was told my colleague never got the executable built as Debug to work. However, this does not seem impossible to me (although I am having linker issues). The runtime library setting of ProcessingLib was /MDd, for ProcessingLibTest it was also /MDd. Building the library as Debug was fine but building the executable as Debug produce the linker errors (ie: value of MD_DynamicRelease not matching value of MDd_DynamicDebug).

If I change ProcessingLibTest from /MDd to /MD, I can build the ProcessingLibTest executable as Debug.

However, 2 things strike me here. First, if both project are built with /MDd, why are they disagreeing? There are other libraries/DLLs involved (some custom written for this project), so could they be a factor? Only, the linker errors complain about ProcessingLib's classes, not libraries, etc beyond it..?

Secondly, why do I have to change The Runtime Library of the executable class (to apparently disagree with ProcessingLib's setting) to get things building?

I have been programming for years but not spent nearly as much time on "properly" debugging C++ code, such as running the debugger, loading symbol (PDB) files and the like. So this is a bit of a learning curve for me.

chadw · J jsulm 6 Jun 2018, 08:57

@jsulm Just to be explicit: Yes, running in release mode without these changes: Never been a problem.
Trying to run in Debug mode: Not been able to build in Debug, until I tackled (and hit these errors) in the last few days.

chadw · 6 Jun 2018, 09:55

@JonB Just building my own libraries and linking against pre-built Qt.
Linker errors originate from main.obj (of my own project, ProcessingLibTest), and referring to object files in my other project (ProcessingLib).

JonB · 6 Jun 2018, 10:41

@chadw
So then you should have just two requirements to meet:

Whatever flags you compile your code with must match the flags for whatever the existing downloaded libraries you wish to link against were compiled with. If /MT is for multi-threaded and /MD is not, given that Qt is heavily multi-threaded I wonder if you need the former.
Your own code must be consistently & completely compiled with same flags. Especially in the case that you have changed the flags in your .pro file, I think you should absolutely clean out all your existing .obj files etc. and ensure you do do a completely fresh rebuild and try again.

chadw · 6 Jun 2018, 11:06

@JonB Actually, looking in Visual Studio, all four options appear to be multi-threaded:

But I take your point for 1), they must agree across all projects.

For 2), I've got a bigger issue. I can't change the value in the .obj files through QtCreator. In VStudio, I can change it using the project properties, rebuild and look in any resulting .obj file. Using the link in my original post, I though the syntax for setting Runtime Library was:

QMAKE_CFLAGS_DEBUG += /MT

or possibly

QMAKE_CFLAGS_RELEASE += /MT

But this doesn't change the built .obj files. I've got the /debug folder open on my second monitor, so I can see object files disappear when I clean the project and reappear when I build it. Is QMAKE_CFLAGS_DEBUG overridden elsewhere, or am I use the wrong flag?

JonB · 6 Jun 2018, 11:07

@chadw
I'm afraid I was only giving you clues: I don't use C++, MSVC or Qt Creator, so you'll need someone else or to Google....

chadw · 6 Jun 2018, 13:54

@JonB Ahh, thank you for trying though.

On a wider note, changing the QMAKE_CFLAGS_RELEASE or QMAKE_CFLAGS_DEBUG flag as I mentioned above doesn't seem to change what ends up inside the different object files. But examining the object (and ProcessingLib.lib) files, I noticed they all have the same settings across both projects.

Looking at the first linker error:

ProcessingLib.lib(processingdefinition.obj):-1: error: LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in main.obj

Looking inside ProcessingLib/debug/ProcessingLib.lib, I see:

/FAILIFMISMATCH:"_MSC_VER=1900" /FAILIFMISMATCH:"_ITERATOR_DEBUG_LEVEL=2" 
/FAILIFMISMATCH:"RuntimeLibrary=MDd_DynamicDebug" /DEFAULTLIB:"msvcprtd" 
/FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0" /DEFAULTLIB:"MSVCRTD" /DEFAULTLIB:"OLDNAMES"

Inside ProcessingLib/debug/pixelprocessor.obj:

/FAILIFMISMATCH:"_MSC_VER=1900" /FAILIFMISMATCH:"_ITERATOR_DEBUG_LEVEL=2" 
/FAILIFMISMATCH:"RuntimeLibrary=MDd_DynamicDebug" /DEFAULTLIB:"msvcprtd" 
/FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0" /DEFAULTLIB:"MSVCRTD" /DEFAULTLIB:"OLDNAMES"

Inside ProcessingLibTest/debug/main.obj:

/FAILIFMISMATCH:"_MSC_VER=1900" /FAILIFMISMATCH:"_ITERATOR_DEBUG_LEVEL=0" 
/FAILIFMISMATCH:"RuntimeLibrary=MDd_DynamicDebug" /DEFAULTLIB:"msvcprtd" 
/FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0" /DEFAULTLIB:"MSVCRTD" /DEFAULTLIB:"OLDNAMES"

In short, RuntimeLibrary=MDd_DynamicDebug, is in violent agreement across the files. The plot thickens.

(PS. For those who spot above that _ITERATOR_DEBUG_LEVEL differ - I took care of that Linker error by: #define _HAS_ITERATOR_DEBUGGING 0 in the complaining header files of ProcessingLibTest)

JonB · 7 Jun 2018, 08:33

@chadw said in How do I change the Runtime Library setting in my project in QtCreator?:

On a wider note, changing the QMAKE_CFLAGS_RELEASE or QMAKE_CFLAGS_DEBUG flag as I mentioned above doesn't seem to change what ends up inside the different object files.

Just a very quick one: I'm not sure the type of flags you were mentioning changing --- e.g. /MD -> /MT --- would necessarily have much/any effect on a .obj file's size/content. If the only difference is that it changes which library the .obj links with, which may be the case for that example, you might not see much change.

chadw · 7 Jun 2018, 08:48

@JonB If I change the RunTime Library option in Visual Studio[1], the RuntimeLibrary setting in the object files change accordingly. My assumption was that setting the relevant QMAKE_CFLAGS_ flag ough to do the same. But as it doesn't change that entry in the object files, my syntax is somehow wrong. Or it's overwritten somewhere else. Or I've got the wrong end of the stick (not for the first time).

[1] Project Properties -> Configuration Properties -> C/C++ -> Code Generation, Runtime Library

JonB · 7 Jun 2018, 12:46

@chadw
(I use VS 2010, though not for Qt, so my interface may be a bit different from yours.)

Suggestion:
When you change your settings in VS, have a look at what VS is actually doing to the command-line, both for compilation & linking. For example, in VS 2010 I have:

Configuration Properties > C/C++ > Command Line
Configuration Properties > Linker > Command Line

Maybe it's making an explicit change to the linker command to account for your change, in addition to the /MDd?

chadw · 6 Jul 2018, 12:49