Cannot run anything from QtCreator



  • Hi,
    I just installed Qt 5.0.1 libraries and QtCreator. However, during the installation process, I disabled compiler installation because I already have mingw32 4.7 installed and working.
    I created a basic project and it compiled fine with the default code. But it doesn't run, and debugging just says me this :
    "During startup program exited with code 0xc0000139."

    I tried to run my program from the file browser, and after copying the required libraries, I got an error saying that the entry point of procedure __gxx_personality_v0 couldn't be found in libstdc++-6.dll. I thought the DLL in Qt SDK differ from the one in MinGW, so I tried to swap them... but same error.

    I saw that this problem was solved by reinstalling Qt, but this is the first time I install Qt on my computer...
    How can I fix this?

    I am on Windows 7 64 bits.


  • Moderators

    welcome to devnet

    It looks like a version issue of MinGW. From personal experience I know that the version numbering of MinGW downloaded from MinGW.org is a bit strange to say the least. If you read a bit sloppy and install without an update of installer information you end up with 4.6.2. And what you have finally installed is not obvious. You need to check that you have at least the definite version with
    @
    g++ --version
    @

    MinGW 4.6.2 and MinGW 4.7.2 are not bit compatible.
    MinGW is not distributed over a single webpage. There are several places around. MinGW.org does not offer a 64 bit version while others do. There seem to be a bit of politics in the back and I have the feeling that MinGW.org might been abundant.

    AFAIK the compilations with the different MinGW 4.7.2 should be compatible (nevertheless you have to observe 32/64 bit incompatibilities).

    Personally I would reinstall Qt SDK including the MinGW compiler after deinstalling MinGW beforehand. This may save you the ifs and whens. Moreover it gives you time to concentrate on your work.



  • I checked the version and its prints "g++ (GCC) 4.7.2", so I guess it should be compatible?
    I don't understand why I should uninstall it, because the same version was indicated in Qt installer Oo is there other configurations to be done?

    EDIT: I told QtCreator to use the MinGW included in the SDK by cloning the default kit, and it works. But I checked its version from the command line, it is 4.7.2 too Oo (both 32 bits)



  • Hallo.

    There are two separate MinGW projects. There's the one you have installed (mingw.org) and the one that ships with Qt/Qt Creator (referred "here":http://en.wikipedia.org/wiki/MinGW as "MinGW-w64 fork", which is a bit of a misnomer, as it also has a 32 bit version). These projects are not binary compatible, even though they may be on the same gcc version.

    So, if you want to use your mingw.org's MinGW, you have to build Qt from source. If you want to use the MinGW-w64/MinGW-w32, just select that toolchain. If you're using other libs (e.g., Boost), you'll have to build those libs with MinGW-w64/MinGW-w32.

    All the libs you link with your app should be built with the MinGW version you're using to build the app.

    BTW, you don't have to uninstall anything, but you should consider whether you actually need these two MinGWs on your system. If you do, you just need to be careful about paths. Qt Creator's kits are a good way of managing this (but you should always double-check each project's Build/Run PATH, to make sure the correct builds of Qt and other libs are available), and you should create cmd prompts for each environment. If you can manage that, you're good to go.



  • Hi,
    This may be related, I have the same problem with VS. QT 5.0.1 win 32 but vs2010 version. I am running on win 64 laptop.

    I ported a working Mac project and it builds but will not run under win 501, just exits immediately before reaching main. I installed 4.8.4 and added it in the kits section. My project does not run with either 501 or 484

    In 484 and 501 my project exits like this
    ModLoad: 0000000075810000 0000000075857000 C:\Windows\syswow64\KERNELBASE.dll
    sProcess exited (3221225781)
    eERROR: Process crashed
    eERROR: CDB crashed



  • [quote author="handaroo" date="1363078203"]Hi,
    In 484 and 501 my project exits like this
    ModLoad: 0000000075810000 0000000075857000 C:\Windows\syswow64\KERNELBASE.dll
    sProcess exited (3221225781)
    eERROR: Process crashed
    eERROR: CDB crashed
    [/quote]

    When you run your app from the command line, do you get any error?


  • Moderators

    [quote author="Zylann" date="1363031312"]
    I don't understand why I should uninstall it, because the same version was indicated in Qt installer Oo is there other configurations to be done?[/quote]
    [quote author="koahnig" date="1363007881"]
    Personally I would reinstall Qt SDK including the MinGW compiler after deinstalling MinGW beforehand. This may save you the ifs and whens. Moreover it gives you time to concentrate on your work. [/quote]
    I think this is already stating, that you do not have to as stated by pcaetano It is more personal recommendation based on long experience.

    pcaetano elaborates also on the version mess with MinGW.
    [quote author="pcaetano" date="1363074621"]These projects are not binary compatible, even though they may be on the same gcc version.[/quote]
    I am not sure if this statement is correct, in another thread in devnet I raised the question and the answer read differently. But assuming that it is correct may save a couple of days of your life.



  • [quote author="koahnig" date="1363081803"]
    pcaetano elaborates also on the version mess with MinGW.
    [quote author="pcaetano" date="1363074621"]These projects are not binary compatible, even though they may be on the same gcc version.[/quote]
    I am not sure if this statement is correct, in another thread in devnet I raised the question and the answer read differently. But assuming that it is correct may save a couple of days of your life.
    [/quote]

    I have both on my system, and whenever I tried to mix them, I've always got errors like this: “The procedure entry point __gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll”.

    Granted, this can have varied causes (e.g., exception handling model - sjls vs. dwarf2), and there may be solutions/workarounds for it, but I always found it safer to follow the rule of keeping these builds separated.

    So, I'd say, for all purposes and intents, unless you're planning on building your own MinGW/gcc from source, it's safer to assume you'll have binary incompatibilities.

    However, you're right that my statement is too categorical, I should probably avoid that.


  • Moderators

    [quote author="pcaetano" date="1363083872"]
    I have both on my system, and whenever I tried to mix them, I've always got errors like this: “The procedure entry point __gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll”.

    Granted, this can have varied causes (e.g., exception handling model - sjls vs. dwarf2), and there may be solutions/workarounds for it, but I always found it safer to follow the rule of keeping these builds separated.[/quote]

    In parallel to my search of statement where I am deriving the compatibility from your post above appeared.

    Here is "the reference":http://qt-project.org/forums/viewthread/23519/P15/#109437 The reference is also in line with your assumption on exception models.

    [quote author="pcaetano" date="1363083872"]So, I'd say, for all purposes and intents, unless you're planning on building your own MinGW/gcc from source, it's safer to assume you'll have binary incompatibilities.
    [/quote]

    It is always the question where your expertise, interest and working fields are. We, developers tend to fiddle around to long, because something should work and we do not know why. Because of this habit we are developers or we have the habit, because we are developers. The difficult thing is to keep it in areas with expertise or what you really need. ;-)



  • [quote author="koahnig" date="1363084762"]
    Here is "the reference":http://qt-project.org/forums/viewthread/23519/P15/#109437 The reference is also in line with your assumption on exception models.
    [/quote]

    Ooh, this is very useful, thanks :)

    [quote author="koahnig" date="1363084762"]
    It is always the question where your expertise, interest and working fields are. We, developers tend to fiddle around to long, because something should work and we do not know why. Because of this habit we are developers or we have the habit, because we are developers. The difficult thing is to keep it in areas with expertise or what you really need. ;-) [/quote]

    Totally agreed. A year ago, after losing contact with development for several years, I've decided to dive back into C++. I've since spent plenty of time fiddling with things that should work. Right now, these are my main tasks:

    • Understand why building QT from git with MSVC 2012 is not including webkit (and no, I didn't exclude it when I ran init-repository). I've posted a question about it here, but got no luck.
    • Understand why a debugging session with Qt Creator keeps jumping semi-haphazardly into NTDLL and similar system libs (ntdll!LdrFindResource_U is a favorite). I'm currently learning more about gdb to run a command-line debug session, to see if it also happens there.

    And I've already solved a problem I had with <QT_HOME>/Tools/MinGW/etc/gdbinit - gdb only found libstdcxx.v6.printers when I added the absolute path to <QT_HOME>/Tools/MinGW/share/gcc-4.7.2/python. sys.path.insert() with a relative path always failed, regardless of the path separators I used. I've even added a "print os.getcwd()", but it was on the correct dir, so, no clue as to why it was failing.

    I also get some random "PC register is not available", but, in light of "this":http://sourceware.org/bugzilla/show_bug.cgi?id=14018, I assume it's something I'll have to live with.

    Once I have my environment stable again, I expect to dive back into C++ again. It's not wasted time, because I'm learning, but sometimes I can't help but wish things just worked :)

    Anyway, thanks for the info.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.