MINGW-packages: gcc seems broken

I managed to reduce the problem to a very simple hello_world.cpp example:

/*
g++ -isystem /mingw64/include hello_world.cpp -o hello_world.exe
fails with:
In file included from C:/msys64/mingw64/include/c++/11.2.0/bits/stl_algo.h:59,
                 from C:/msys64/mingw64/include/c++/11.2.0/algorithm:62,
                 from C:/msys64/mingw64/include/QtCore/qglobal.h:142,
                 from C:/msys64/mingw64/include/QtCore/qchar.h:43,
                 from C:/msys64/mingw64/include/QtCore/qstring.h:49,
                 from C:/msys64/mingw64/include/QtCore/QString:1,
                 from hello_world.cpp:5:
C:/msys64/mingw64/include/c++/11.2.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
   75 | #include_next <stdlib.h>
      |               ^~~~~~~~~~
compilation terminated.

Removing "-isystem /mingw64/include" fixes the problem

*/

#include <QtCore/QString>

int main(int argc, char *argv[]) {
  printf("Hello World!\n");
  return 1;
}

Sounds like an gcc issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129

Yes, luckily the fix is very simple: remove -isystem /mingw64/include. I just applied it here so that we can compile our application again.

We can probably close the issue now.

There is a core change in system crt and headers. So, GCC is being rebuilt in CI right now. Please wait for the fix.

GCC upgrade to 11.2.0-9

Ty @lazka @Biswa96 but it still breaks for me with the latest gcc upgrade you pushed, it looks like similar to the issue @omichel is having

Unexpected behavior

CLion is no more capable of using a MinGW toolchain under Windows and is displaying the message Not found

Log of what is behind “Not found”

I enabled the log of category #com.jetbrains.cidr.cpp and found the following relevant issue

2022-02-17 10:19:47,928 [ 625373]   INFO -        #com.jetbrains.cidr.cpp - No output for command: C:\tools\clion\bin\cmake\win\bin\cmake.exe -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY -G "NMake Makefiles" C:\Users\ufleadv\AppData\Local\Temp\cmake_check_environment 
2022-02-17 10:19:48,568 [ 626013]  DEBUG -        #com.jetbrains.cidr.cpp - MinGW.readVersion() file: 'C:\tools\msys2\ucrt64' error 
java.io.FileNotFoundException: C:\tools\msys2\ucrt64\x86_64-w64-mingw32\include\_mingw.h (Le chemin d’accès spécifié est introuvable)
	at java.base/java.io.FileInputStream.open0(Native Method)

Does not seem to be exactly linked to this issue, rather it seems you may just have issues with linking, not with the headers. You may want to research more on linking in general, but as a start point, I would suggest looking into how to use pkg-config.

If you want an exact answer, try running

gcc $(pkgconf --static --cflags jansson libcurl) main.c $(pkgconf --static --libs jansson libcurl)

instead of just gcc main.c. The output of the command pkgconf --static --libs jansson libcurl will tell gcc which libraries you will need to be able to link against jansson and curl.

Example of the issue happening with -isystem: https://github.com/NazaraEngine/NazaraEngine/runs/7413695221?check_suite_focus=true#step:12:4179

error: In file included from D:\a\NazaraEngine\xmake-global\.xmake\packages\a\assimp\v5.2.4\0b973729606a40aab7f2fb4696cf8a63\include/assimp/vector2.h:53,
                 from D:\a\NazaraEngine\xmake-global\.xmake\packages\a\assimp\v5.2.4\0b973729606a40aab7f2fb4696cf8a63\include/assimp/types.h:64,
                 from D:\a\NazaraEngine\xmake-global\.xmake\packages\a\assimp\v5.2.4\0b973729606a40aab7f2fb4696cf8a63\include/assimp/Importer.hpp:60,
                 from D:\a\_temp\msys64\tmp\.xmake\220719\_9FBCAB64B619410AA5B53DAE28D84EC2.cpp:2:
D:/a/_temp/msys64/mingw64/include/c++/12.1.0/cmath:45:15: fatal error: math.h: No such file or directory
   45 | #include_next <math.h>
      |               ^~~~~~~~
compilation terminated.

core/glibc 2.35-6 [installed]
    usr/include/bits/stdlib.h
    usr/include/stdlib.h

you’re looking at the wrong package, the ones provided by the c++ related packages are supposed to be helper includes for C++ code when including the .h version rather than cstdlib

i reverted all the path changes in my local build and so far all seems to run again except some problem building qt6 but i think that is unrelated to this issue since it also failed with the original compiler.

I’ve seen it from time to time crop up in CI, so I’m wondering if some part of it is not deterministic.

No problem on my side after today’s update, everything compiles smoothly.

So for somebody confused by the thread here, the issue is that the sysroot parameter isn’t working with GCC anymore?

I’m having the same issue with my MinGW64 CI: https://github.com/DigitalPulseSoftware/NazaraEngine/runs/5231389195?check_suite_focus=true#step:10:52

Edit: Issue reported to the CLion team here https://youtrack.jetbrains.com/issue/CPP-28403

@Biswa96

indeed I think CLion checks for a static file location for checking the validity of the toolchain because that’s what show the Java stacktrace

java.io.FileNotFoundException: C:\tools\msys2\ucrt64\x86_64-w64-mingw32\include\_mingw.h (Le chemin d’accès spécifié est introuvable)
	at java.base/java.io.FileInputStream.open0(Native Method)
	at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
	at java.base/java.io.FileInputStream.<init>(FileInputStream.java:157)
	at com.intellij.openapi.util.io.FileUtilRt.loadFileText(FileUtilRt.java:755)
	at com.intellij.openapi.util.io.FileUtilRt.loadFile(FileUtilRt.java:744)
	at com.intellij.openapi.util.io.FileUtilRt.loadFile(FileUtilRt.java:729)
	at com.intellij.openapi.util.io.FileUtil.loadFile(FileUtil.java:1405)
	at com.jetbrains.cidr.cpp.toolchains.MinGW.readVersion(MinGW.java:108)
	at com.jetbrains.cidr.cpp.toolchains.MinGW.readVersion(MinGW.java:88)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$3.readAndCheckVersion(ToolchainPanel.kt:317)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$3.readAndCheckVersion(ToolchainPanel.kt:311)
	at com.jetbrains.cidr.cpp.toolchains.VersionChecker.check(CPPToolchainsUIUtils.kt:193)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$addVersionChecker$checkerRunnable$1.runInBackground(ToolchainPanel.kt:648)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$addVersionChecker$checkerRunnable$1.runInBackground(ToolchainPanel.kt:641)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$addChecker$runnable$1$run$1$backgroundFunction$1.invoke(ToolchainPanel.kt:861)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$addChecker$runnable$1$run$1$backgroundFunction$1.invoke(ToolchainPanel.kt:836)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$sam$java_lang_Runnable$0.run(ToolchainPanel.kt)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:624)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:698)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:646)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:623)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:66)
	at com.jetbrains.cidr.cpp.toolchains.ui.ToolchainPanel$addChecker$runnable$1$run$1.run(ToolchainPanel.kt:862)
	at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:240)
	at com.intellij.util.Alarm$Request.runSafely(Alarm.java:385)
	at com.intellij.util.Alarm$Request.run(Alarm.java:374)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at com.intellij.util.concurrency.SchedulingWrapper$MyScheduledFutureTask.run(SchedulingWrapper.java:220)
	at com.intellij.util.concurrency.BoundedTaskExecutor.doRun(BoundedTaskExecutor.java:246)
	at com.intellij.util.concurrency.BoundedTaskExecutor.access$200(BoundedTaskExecutor.java:32)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.execute(BoundedTaskExecutor.java:225)
	at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:213)

Ty for helping out guys, I think I don’t have a better solution yet than creating a symlink while waiting for the newest CLion 2022.1 😃

thanks, yeah, something is still off.

I can’t reproduce though.

OK, thank you for the quick reply!