Qt Creator and other tools

@cristian-adam Hi, unfortunately no crash dumps are collected.

https://download.qt.io/official_releases/qtcreator/13.0/13.0.1/ Are you sure you only need QtCreator? Maybe you also need Qt?

Qt Creator 13.0.x comes with LLVM 17. Just upgrade to https://download.qt.io/official_releases/qtcreator/13.0/

Update on Cross-Compiling In the mean time I created GitHub repository which demonstrates the use of a privately hosted Docker image assembled by using this GitHub repository and its script cpp-builder.sh. (It is a lot easier to download/pull the Docker image from nexus.scanframe.com:8090/gnu-cpp:dev) It accommodates building Qt Linux and Windows targets as well as performing unit testing. A GitLab runner uses it to execute a pipeline which executes a CMakePreset-workflow. The same Docker image is used to build, run, debug and test locally by mounting the X-server socket into the Docker VM. Preset allow workflows and individual presets to be executed using the script docker-build.sh. [image: 54a39532-fcca-49c9-bd87-cd0c54bc5837.png] Hopefully someone can benefit from my work on this :)

@Brynjolf Have You figured something out?

@sierdzio For future reference, this did not solve the issue.

@anushka_prajose said in How to resolve error : No compiler can produce code for this Qt version. Please define one or more compilers for: x86-linux-generic-elf-64bit: What should be done ? You need Qt built for your target device. The device uses an ARM CPU as far as I can see and you're trying to use Qt built for x86_64 - this is not going to work. Please use shorter titles for your posts.

@Ran_Flora As @Christian-Ehrlicher has said, the error message about "missing } for {" immediately after #include <iostream> makes it seem like that file (or something it includes) is somehow incorrect.....

Okay, i found a way to do it i was looking in the QStandardModel documentation, thinking it would be there, but I found it in the QAbstractItemView documentation.

@GAlbert maybe you can try to customize Tab Bar if you use qtabwidget

Please post your .pro file (if using qmake) or CMakeLists.txt (if using cmake), maybe we'll spot some error there.

This behavior points at a corrupted project tree. It can happen e.g. when files were moved or renamed on disk, without using the rename function of Qt Creator. So the bug is outside of Qt. If memory serves well, we had a discussion about project file structure in another thread. That’s probably related. I also seem to remember that you asked the question before, in answered it, you reported a bug and I closed it for exactly the reason I explained.

I had the same problem. Try these steps: Delete the %APPDATA%/QtProject folder. You may want to make a backup copy first, as all your QtCreator settings will be reset. If step 1 does not help, try reinstalling the MSVC compiler and CDB debugger (installed separately using Debugging Tools for Windows). I didn’t look into the problem in more detail, it seems like something happened to the debugger configuration.

@JKSH said in Is it a bug in Qt Creator?: @open-src Looks like Qt Design Studio doesn't handle absolute paths in importPaths. Thanks, that‘s what I means. @JKSH said in Is it a bug in Qt Creator?: But I agree with the others: it is not a good idea to develop, build, and test apps as root Thanks, I know it, and I won't be using the root user in my official work.

Great, works also for me. Thanks.

@Christian-Ehrlicher I'm convinced you're right for most use cases and applications. I also agree that relying on the working directory causes some hurt. But, I'm dealing with a game with hundreds of megabytes of assets. Baking this stuff into the executable would increase build times, even doing asset-pack files during dev-builds would slow things down. -> More Hurt. Regarding absolute paths: Maybe I'm missing something, what problem do you see with a project wide environment variable for my use case? Sometimes I have to compare two different checkouts of the same code base, so I have two project directories of the same code base at different commits (including assets) and build-A-GCC-Release/bin/foo needs assets from A/... and build-B-clang-Debug/bin/foo needs assets from B/...). So hardcoding paths or using defines or even having user wide configs (e.g. ~/.config/...).