Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. How do I change the Runtime Library setting in my project in QtCreator?
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Solved General and Desktop
14 Posts 3 Posters 11.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C Offline
    C Offline
    chadw
    wrote on last edited by
    #4

    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.

    1 Reply Last reply
    0
    • jsulmJ jsulm

      @chadw Did you try to build in debug mode?

      C Offline
      C Offline
      chadw
      wrote on last edited by
      #5

      @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.

      1 Reply Last reply
      0
      • JonBJ JonB

        @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?

        C Offline
        C Offline
        chadw
        wrote on last edited by
        #6

        @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).

        JonBJ 1 Reply Last reply
        0
        • C chadw

          @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).

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by
          #7

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

          1. 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.

          2. 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.

          C 1 Reply Last reply
          0
          • JonBJ JonB

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

            1. 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.

            2. 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.

            C Offline
            C Offline
            chadw
            wrote on last edited by
            #8

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

            0_1528280862758_afe7a7ac-85af-4026-ae67-1b056dd68a7d-image.png

            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?

            JonBJ 1 Reply Last reply
            0
            • C chadw

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

              0_1528280862758_afe7a7ac-85af-4026-ae67-1b056dd68a7d-image.png

              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?

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by JonB
              #9

              @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....

              C 1 Reply Last reply
              0
              • JonBJ JonB

                @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....

                C Offline
                C Offline
                chadw
                wrote on last edited by chadw
                #10

                @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)

                JonBJ 1 Reply Last reply
                0
                • C chadw

                  @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)

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by
                  #11

                  @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.

                  C 1 Reply Last reply
                  0
                  • JonBJ JonB

                    @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.

                    C Offline
                    C Offline
                    chadw
                    wrote on last edited by
                    #12

                    @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

                    JonBJ 1 Reply Last reply
                    0
                    • C chadw

                      @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

                      JonBJ Offline
                      JonBJ Offline
                      JonB
                      wrote on last edited by
                      #13

                      @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?

                      C 1 Reply Last reply
                      0
                      • JonBJ JonB

                        @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?

                        C Offline
                        C Offline
                        chadw
                        wrote on last edited by chadw
                        #14

                        @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:

                        0_1528375186350_36fe16b6-fec3-4511-ad1a-0ee4da06993f-image.png

                        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.

                        1 Reply Last reply
                        1

                        • Login

                        • Login or register to search.
                        • First post
                          Last post
                        0
                        • Categories
                        • Recent
                        • Tags
                        • Popular
                        • Users
                        • Groups
                        • Search
                        • Get Qt Extensions
                        • Unsolved