Skip to content
QtWS25 Call for Papers
  • 0 Votes
    8 Posts
    436 Views
    jsulmJ

    @joej said in g++: error: /DEBUG: No such file or directory:

    MSVC compiler (x86-windows-msvc2005-pe-32bit) cannot produce code for "Qt 5.12.12 MSVC2017 32bit"

    Use newer MSVC compiler

  • 0 Votes
    2 Posts
    183 Views
    jsulmJ

    @Leoo Please post your pro file (as text not pictures).

  • 0 Votes
    2 Posts
    222 Views
    Christian EhrlicherC

    Since Qt6 does not support Windows 7 anymore you have to choose an older qt installer from e.g. https://mirror.netcologne.de/qtproject/archive/online_installers/

  • 0 Votes
    9 Posts
    789 Views
    C

    @Christian-Ehrlicher Thank you for clarifying!

  • 0 Votes
    25 Posts
    2k Views
    Christian EhrlicherC

    Here the bug report for this issue: https://bugreports.qt.io/browse/QTBUG-78086

  • 0 Votes
    11 Posts
    662 Views
    Christian EhrlicherC

    @artwaw said in QtSql Postgress MinGW8 compilation error.:

    I always use QtCore to avoid the plethora of single class includes.

    Looks like you have enough time...

  • 0 Votes
    4 Posts
    224 Views
    C

    There are no debug libraries in the binary folder containing the runtime used by Qt Creator (i.e. ...\Qt\Tools\QtCreator\bin.

    There should be under the folder for each Qt library version you have installed, and these are the libraries that your program should be built against/link to. I would guess the path should be ...\Qt\6.1.2\mingw32\lib and ...\bin (no Windows install in front of me).

  • A problem about assert in QT

    Unsolved General and Desktop
    8
    0 Votes
    8 Posts
    2k Views
    C

    @KH-219Design
    thank you, I‘ll try some tests.

  • 0 Votes
    4 Posts
    343 Views
    E

    @jsulm Yoo,thanks bro

  • 0 Votes
    5 Posts
    2k Views
    S

    @SGaist That was my problem. I compiled the libraries with MinGW 32 while my Qt's is MinGW 64. I changed the compiler and the problem is solved.
    Thanks for the help.

  • 0 Votes
    2 Posts
    253 Views
    SGaistS

    Hi,

    It's rather the other way around. Choose the most recent version of MinGW that supports what you need and then patch your version of Qt if needed to build.

    Beside the fact that Qt 4 has reached end of life a long time ago, you should at least move to Qt 4.8.7.

  • 0 Votes
    8 Posts
    1k Views
    JonBJ

    @Mixlu
    There are two possible issues. crypt.h is only a #include header file, needed to compile. Separately is the library containing the crypt code, which you will need at link-time (else "unresolved reference error") and/or run-time. Depending on your platform, we might be talking about libcrypt.a, libcrypt.so and/or libcrypt.dll. (For MinGW I also see mentions of libgcrypt, I don't know if that is relevant to you.) You will need one of these too, unless the crypt code is already actually in some other supplied runtime library.

    If you are Windows (you are, aren't you?) you might like to look at e.g. https://stackoverflow.com/questions/48410282/mingw32-compiler-giving-error-with-lcrypt

  • 0 Votes
    3 Posts
    4k Views
    S

    Adding "[...]/mingw73_32/bin" to PATH worked! Thank you

  • 0 Votes
    8 Posts
    742 Views
    SGaistS

    Are you trying to move things around in the folder where you are currently doing the application deployment ?

  • PeakCAN Mingw

    Solved General and Desktop
    4
    0 Votes
    4 Posts
    799 Views
    aha_1980A

    Hi @wimschuiteman,

    Peak does not distinguish between 32 and 64 bit, the library is called pcanbasic.dll in both cases.

    So you need to use the correct one, 32 or 64 bit, depending on your Qt architecture.

  • 0 Votes
    6 Posts
    2k Views
    SGaistS

    Glad you found out and thanks for sharing !

  • 1 Votes
    34 Posts
    11k Views
    E

    @JonB well, I thought it just creates a new build file for the new compiler (which it does), but I have to admit my understanding for compilers is not very deep.

  • 0 Votes
    6 Posts
    3k Views
    Pablo J. RoginaP

    @A-Trujillo si tu problema está solucionado, por favor no te olvides de marcar tu pregunta como tal. Muchas gracias.

  • 0 Votes
    19 Posts
    11k Views
    K

    @fem_dev said in Build with mingw32-make *very* slow:

    First Question

    Qt Creator starts to use jom, but I got this compile time errors:

    09:35:09: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" exited normally. 09:35:09: Starting: "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" -j4 jom 1.1.3 - empower your colors cd App / && (test -e Makefile || C: /Qt/5.15.0/mingw81_64/bin/qmake.exe -o Makefile C: /Users/VM/Desktop/rotortest/App/App.pro -spec win32- g ++ CONFIG + = debug CONFIG + = qml_debug) && C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe -f Makefile C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe -f Makefile.Debug 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/app.ui -o ui_app.h The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_app.h] Error 1 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/custom_widget/value_unit.ui -o ui_value_unit.h 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/form/form_assembly.ui -o ui_form_assembly.h 'C: \ Qt \ 5.15.0 \ mingw81_64 \ bin \ uic.exe' ../../rotortest/App/form/form_excitation.ui -o ui_form_excitation.h The syntax of the file name, directory name, or volume label is incorrect. The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_form_assembly.h] Error 1 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_value_unit.h] Error 1 The syntax of the file name, directory name, or volume label is incorrect. jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile.Debug [ui_form_excitation.h] Error 1 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ App \ Makefile [debug] Error 2 jom: C: \ Users \ VM \ Desktop \ build-rotortest-Desktop_Qt_5_15_0_MinGW_64_bit-Debug \ Makefile [sub-App-make_first] Error 2 09:35:10: The process "C: \ Qt \ Tools \ QtCreator \ bin \ jom.exe" exited with code 2. Error while building / deploying project rotortest (kit: Desktop Qt 5.15.0 MinGW 64-bit) When executing step "Make"

    How can I fix it?

    My system:

    Qt Creator 4.12.4 (GCC based - downloaded by MSYS2) Qt 5.15.0 Windows 10 x64 Mingw-w64 jom

    Should be completely irrelevant. When your make file works with mingw-make, it has to work with jom as well. jomis a replacement for nmake because it did not allow -j parameter. AFAIK the MSVC does support directly multi-threading and it is not done through nmake.

    Besides possible side effects through parallel access to the same file or whatever, there is no difference for compilation. You are listing compile errors which are due to the compiler you are using.

    Second question

    @koahnig said in Build with mingw32-make *very* slow:

    Mingw-make does support now multi-threading. I did some tests back then, but after a reinstall, there was no need anymore.

    Are you saying that you compiled your Qt project using the default MSYS2 Mingw-64 configuration (WITHOUT jom) and got a close time compilation speed compared with MSVC 2019?

    Nope. I do not use MSVC 2019 compiler at all. AFAIK there was an issue with an older MinGW-make not suporting multi-threading. Therefore this discussion and the solution with jom. After my reinstall I did not bother to set up jom again. At day's end some gain is possible by switching to jom, but it was not enough to go through the hassle again.

    You seem to use a self-compiled Qt creator version. The output shows strange blanks around the backslashes. Possibly there is your problem with compilation.

  • 0 Votes
    4 Posts
    1k Views
    K

    @Hjortronsylt

    Well libraries are simply not interchangable. Each library does hold a couple of objects defining typically the functionality given in the general naming.

    Some namings may have changed between Qt4 and Qt5, but not network to anything.

    Also when your application is requiring network functionality, but is missing it in the link process, you should see somewhere error messages.

    I would suggest that it is best when you are checking out examples from the tutorials. There are the network examples and there is the testlib functionality
    however, Qt offers more different aspects and it may make sense for you to check out those as well.