Open omichel opened 2 years ago
There is a core change in system crt and headers. So, GCC is being rebuilt in CI right now. Please wait for the fix.
OK, thank you for the quick reply!
@Biswa96
Is it related to the following behavior or do I need to open a newer ticket for this ?
headers are located in tar/ucrt64/x86_64-w64-mingw32/include
headers are also located in tar/ucrt64/x86_64-w64-mingw32/include
headers are relocated to tar/ucrt64/include
Thank you for helping
PS: @omichel If this is same behavior, a temp fix is to symlink x86_64-w64-mingw32/include
to ..\include
Oh, I didn't realize that the gcc update was needed since I build various things without it locally.
I'll look into updating things
Please try again now.
Nope: I am still getting the exact same error after updating to the latest gcc packages:
$ pacman -Syuu
:: Synchronizing package databases...
mingw32 1448.3 KiB 559 KiB/s 00:03 [#####################] 100%
mingw64 1455.3 KiB 1704 KiB/s 00:01 [#####################] 100%
ucrt64 1587.8 KiB 2.70 MiB/s 00:01 [#####################] 100%
clang64 1500.3 KiB 889 KiB/s 00:02 [#####################] 100%
msys is up to date
:: Starting core system upgrade...
there is nothing to do
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (5) mingw-w64-i686-gcc-11.2.0-9 mingw-w64-i686-gcc-libs-11.2.0-9
mingw-w64-x86_64-gcc-11.2.0-9
mingw-w64-x86_64-gcc-libgfortran-11.2.0-9
mingw-w64-x86_64-gcc-libs-11.2.0-9
Total Download Size: 60.12 MiB
Total Installed Size: 338.72 MiB
Net Upgrade Size: -0.01 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
mingw-w64-x86_64... 761.0 KiB 713 KiB/s 00:01 [#####################] 100%
mingw-w64-x86_64... 827.8 KiB 734 KiB/s 00:01 [#####################] 100%
mingw-w64-i686-g... 886.5 KiB 730 KiB/s 00:01 [#####################] 100%
mingw-w64-x86_64... 28.5 MiB 5.64 MiB/s 00:05 [#####################] 100%
mingw-w64-i686-g... 29.2 MiB 3.65 MiB/s 00:08 [#####################] 100%
Total (5/5) 60.1 MiB 7.49 MiB/s 00:08 [#####################] 100%
(5/5) checking keys in keyring [#####################] 100%
(5/5) checking package integrity [#####################] 100%
(5/5) loading package files [#####################] 100%
(5/5) checking for file conflicts [#####################] 100%
(5/5) checking available disk space [#####################] 100%
:: Processing package changes...
(1/5) upgrading mingw-w64-i686-gcc-libs [#####################] 100%
(2/5) upgrading mingw-w64-i686-gcc [#####################] 100%
(3/5) upgrading mingw-w64-x86_64-gcc-libs [#####################] 100%
(4/5) upgrading mingw-w64-x86_64-gcc [#####################] 100%
(5/5) upgrading mingw-w64-x86_64-gcc-libgfortran [#####################] 100%
...
$ make
...
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 ../../include/qt/QtCore/QtCore/qglobal.h:137,
from ../../include/qt/QtCore/QtCore/qpair.h:43,
from ../../include/qt/QtCore/QtCore/qarraydata.h:44,
from ../../include/qt/QtCore/QtCore/qarraydataops.h:44,
from ../../include/qt/QtCore/QtCore/qarraydatapointer.h:43,
from ../../include/qt/QtCore/QtCore/qlist.h:44,
from ../../include/qt/QtCore/QtCore/QList:1,
from sound/WbContactSoundManager.hpp:22,
from sound/WbSoundEngine.cpp:17:
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>
| ^~~~~~~~~~
thanks, yeah, something is still off.
I can't reproduce though.
@class101 those relocations are on purpose, see #10634
@omichel Please provide the project link and details about how to compile it.
It's there: https://github.com/cyberbotics/webots/wiki/Windows-installation/ It should be pretty easy to proceed as many tasks are automatic. Let me know if you have any question.
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
CLion is no more capable of using a MinGW toolchain under Windows and is displaying the message 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)
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 :)
I'm having the same issue with my MinGW64 CI: https://github.com/DigitalPulseSoftware/NazaraEngine/runs/5231389195?check_suite_focus=true#step:10:52
@SirLynix If I run xmake it starts to build all the dependencies. Some of them are already in mingw packages. Is it possible not to build all those dependencies from source? BTW, it may be better to discuss an issue in that repository. This thread will be going longer.
@SirLynix If I run xmake it starts to build all the dependencies. Some of them are already in mingw packages. Is it possible not to build all those dependencies from source? BTW, it may be better to discuss an issue in that repository. This thread will be going longer.
Sure. XMake should be able to detect already installed libraries, could you tell me which libraries were already on your system and were recompiled by xmake?
I ran this:
xmake config --shadernodes=y --tests=y --arch=x86_64 --mode=releasedbg --verbose --yes --plat=mingw --mingw=/ucrt64
First, it tries to build assimp. In the output, all the dependencies are shown in red no.
It should give you a list of the missing packages before installing them, was there only assimp on it?
Since this isn't relevant to this issue, feel free to send me a mail or open an issue on my repository.
I think I ran into the same experience:
-- The CXX compiler identification is GNU 10.0.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /builds/free-astro/siril/.local/share/crossroad/bin/x86_64-w64-mingw32-g++
-- Check for working CXX compiler: /builds/free-astro/siril/.local/share/crossroad/bin/x86_64-w64-mingw32-g++ - broken
CMake Error at /usr/share/cmake-3.22/Modules/CMakeTestCXXCompiler.cmake:62 (message):
The C++ compiler
"/builds/free-astro/siril/.local/share/crossroad/bin/x86_64-w64-mingw32-g++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /builds/free-astro/siril/subprojects/librtprocess/_build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/gmake -f Makefile cmTC_e4c38/fast && /usr/bin/gmake -f CMakeFiles/cmTC_e4c38.dir/build.make CMakeFiles/cmTC_e4c38.dir/build
gmake[1]: Entering directory '/builds/free-astro/siril/subprojects/librtprocess/_build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_e4c38.dir/testCXXCompiler.cxx.obj
/builds/free-astro/siril/.local/share/crossroad/bin/x86_64-w64-mingw32-g++ -o CMakeFiles/cmTC_e4c38.dir/testCXXCompiler.cxx.obj -c /builds/free-astro/siril/subprojects/librtprocess/_build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
Linking CXX executable cmTC_e4c38.exe
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_e4c38.dir/link.txt --verbose=1
/usr/bin/cmake -E rm -f CMakeFiles/cmTC_e4c38.dir/objects.a
/usr/bin/x86_64-w64-mingw32-ar qc CMakeFiles/cmTC_e4c38.dir/objects.a @CMakeFiles/cmTC_e4c38.dir/objects1.rsp
/builds/free-astro/siril/.local/share/crossroad/bin/x86_64-w64-mingw32-g++ -Wl,--whole-archive CMakeFiles/cmTC_e4c38.dir/objects.a -Wl,--no-whole-archive -o cmTC_e4c38.exe -Wl,--out-implib,libcmTC_e4c38.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/cmTC_e4c38.dir/linklibs.rsp
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_app_type[.refptr.mingw_app_type]+0x0): undefined reference to `mingw_app_type'
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initcharmax[.refptr.mingw_initcharmax]+0x0): undefined reference to `mingw_initcharmax'
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltssuo_force[.refptr.mingw_initltssuo_force]+0x0): undefined reference to `mingw_initltssuo_force'
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltsdyn_force[.refptr.mingw_initltsdyn_force]+0x0): undefined reference to `mingw_initltsdyn_force'
/usr/bin/x86_64-w64-mingw32-ld: /usr/lib/gcc/x86_64-w64-mingw32/10-posix/../../../../x86_64-w64-mingw32/lib/crt2.o:crtexe.c:(.rdata$.refptr.mingw_initltsdrot_force[.refptr.mingw_initltsdrot_force]+0x0): undefined reference to `mingw_initltsdrot_force'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_e4c38.dir/build.make:101: cmTC_e4c38.exe] Error 1
gmake[1]: Leaving directory '/builds/free-astro/siril/subprojects/librtprocess/_build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:127: cmTC_e4c38/fast] Error 2
https://gitlab.com/free-astro/siril/-/jobs/2107398233
But difficult to say as the output is different. Is this something that will be fixed? Or need I to change something?
@lazka : maybe the log could help you to reproduce.
I had a similar problem, building libtiff on mingw ci failed, stdint.h not found
But it worked a few days ago.
https://github.com/xmake-io/xmake-repo/runs/5234506913?check_suite_focus=true
-- Looking for stdint.h
-- Looking for stdint.h - not found
-- Looking for stddef.h
-- Looking for stddef.h - not found
-- Check size of size_t
-- Check size of size_t - failed
CMake Error at cmake/TypeSizeChecks.cmake:51 (message):
Unsupported size_t size ; please add support
git clone https://github.com/xmake-io/xmake-repo.git
cd xmake-repo
xmake l scripts/test.lua -vD --shallow -p mingw libtiff
@waruqi I am not sure what happen in xmake. I have compiled libtiff from source using CMake and Ninja and it builds fine. Here are my steps:
git clone --depth=1 https://gitlab.com/libtiff/libtiff.git
cd libtiff
cmake -B build -S .
ninja -C build
And here is the same output in cmake where xmake failed.
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of size_t
-- Check size of size_t - done
@lock042 /usr/bin/x86_64-w64-mingw32-ld
is not the path of mingw compiler in msys2. It seems that you are using cross compiler in Linux environment.
@Biswa96 : yes I use crossroad that uses Msys2. The CI failed after Msys2 update.
I use crossroad that uses Msys2.
Then the issue should be reported crossroad. Feel free to ping me there. Or you can also use msys2 in GitLab. Many projects like pango, gstreamer etc. use msys2 in GitLab CI.
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;
}
/include/c++/11.2.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
Sounds like an gcc issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
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.
@waruqi I am not sure what happen in xmake. I have compiled libtiff from source using CMake and Ninja and it builds fine. Here are my steps:
git clone --depth=1 https://gitlab.com/libtiff/libtiff.git cd libtiff cmake -B build -S . ninja -C build
And here is the same output in cmake where xmake failed.
-- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of size_t -- Check size of size_t - done
It will set -DCMAKE_SYSROOT=D:/a/_temp/msys64/mingw64
as sysroot to cmake when I am running xmake to call cmake to build libtiff on my msys/mingw ci.
If I set CMAKE_SYSROOT, this problem comes up, If I remove it, everything works fine.
But a few days ago everything was ok and I didn't make any other changes. It works fine even with CMAKE_SYSROOT set.
If I set CMAKE_SYSROOT, this problem comes up, If I remove it, everything works fine.
So, it is not required anymore, isn't that a feature? 😄 As far as I know, CMAKE_SYSROOT passes --sysroot
option to compiler to find system headers and libs. It is required to say like, hey compiler, instead of searching /usr/include
, search /mydir/usr/include
. More here https://sourceforge.net/p/mingw-w64/wiki2/Native%20Win64%20compiler/
If I set CMAKE_SYSROOT, this problem comes up, If I remove it, everything works fine.
So, it is not required anymore, isn't that a feature? 😄 As far as I know, CMAKE_SYSROOT passes
--sysroot
option to compiler to find system headers and libs. It is required to say like, hey compiler, instead of searching/usr/include
, search/mydir/usr/include
. More here https://sourceforge.net/p/mingw-w64/wiki2/Native%20Win64%20compiler/
But why was it working fine before? I think even if this is a feature, it shouldn't break previous behavior. Also, even if I pass in /mingw64 as sysroot, if these c library files also exist in /mingw64/include, gcc should be able to find them.
Do these header files no longer exist in the /mingw64/include directory?
@Biswa96
Is it related to the following behavior or do I need to open a newer ticket for this ?
mingw-w64-ucrt-x8664-headers-git -> 9.0.0.6364.2194d504e-1
headers are located in
tar/ucrt64/x86_64-w64-mingw32/include
mingw-w64-ucrt-x86_64-headers-git -> 9.0.0.6373.5be8fcd83-1
headers are also located in
tar/ucrt64/x86_64-w64-mingw32/include
mingw-w64-ucrt-x86_64-headers-git -> 9.0.0.6373.5be8fcd83-2
headers are relocated to
tar/ucrt64/include
Thank you for helping
PS: @omichel If this is same behavior, a temp fix is to symlink
x86_64-w64-mingw32/include
to..\include
Oh, I see, the original header file path structure has changed. I think it will break a lot of projects.
I pinged Jehan from crossroad. However, I think our errors are related to the change of path in msys2. Another example of failing build at config stage:
../meson.build:227:0: ERROR: C shared or static library 'm' not found
Cheers
../meson.build:227:0: ERROR: C shared or static library 'm' not found
libm should be ignored in Win32 platform.
So for somebody confused by the thread here, the issue is that the sysroot parameter isn't working with GCC anymore?
qt6-shadertools UCRT64 build
2022-02-18T22:58:17.3902443Z FAILED: src/shadertools/CMakeFiles/ShaderTools.dir/qshaderbatchablerewriter.cpp.obj
2022-02-18T22:58:17.3935183Z D:\a\msys64\ucrt64\bin\g++.exe -DMINGW_HAS_SECURE_API=1 -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT -DQT_BUILD_SHADERTOOLS_LIB -DQT_CORE_LIB -DQT_DEPRECATED_WARNINGS -DQT_DEPRECATED_WARNINGS_SINCE=0x060000 -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_GUI_LIB -DQT_MOC_COMPAT -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_USE_QSTRINGBUILDER -DShaderTools_EXPORTS -DUNICODE -DWIN32 -DWIN64 -DWINVER=0x0A00 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -D_USE_MATH_DEFINES -D_WIN32_WINNT=0x0A00 -D_WIN64 -IC:/M/mingw-w64-qt6-shadertools/src/build-UCRT64/src/shadertools/ShaderTools_autogen/include -IC:/M/mingw-w64-qt6-shadertools/src/build-UCRT64/include -IC:/M/mingw-w64-qt6-shadertools/src/build-UCRT64/include/QtShaderTools -IC:/M/mingw-w64-qt6-shadertools/src/qtshadertools-everywhere-src-6.2.3/src/shadertools -IC:/M/mingw-w64-qt6-shadertools/src/build-UCRT64/src/shadertools -IC:/M/mingw-w64-qt6-shadertools/src/qtshadertools-everywhere-src-6.2.3/src/shadertools/../3rdparty/SPIRV-Cross -IC:/M/mingw-w64-qt6-shadertools/src/qtshadertools-everywhere-src-6.2.3/src/shadertools/../3rdparty/glslang -IC:/M/mingw-w64-qt6-shadertools/src/build-UCRT64/include/QtShaderTools/6.2.3 -IC:/M/mingw-w64-qt6-shadertools/src/build-UCRT64/include/QtShaderTools/6.2.3/QtShaderTools -isystem D:/a/msys64/ucrt64/include/qt6/QtCore -isystem D:/a/msys64/ucrt64/include/qt6 -isystem D:/a/msys64/ucrt64/share/qt6/mkspecs/win32-g++ -isystem D:/a/msys64/ucrt64/include/qt6/QtGui -isystem D:/a/msys64/ucrt64/include -isystem D:/a/msys64/ucrt64/include/qt6/QtGui/6.2.3 -isystem D:/a/msys64/ucrt64/include/qt6/QtGui/6.2.3/QtGui -isystem D:/a/msys64/ucrt64/include/qt6/QtCore/6.2.3 -isystem D:/a/msys64/ucrt64/include/qt6/QtCore/6.2.3/QtCore -march=x86-64 -mtune=generic -O2 -pipe -g -DNDEBUG -O2 -fvisibility=hidden -fno-keep-inline-dllexport -Wall -Wextra -Wsuggest-override -std=c++17 -MD -MT src/shadertools/CMakeFiles/ShaderTools.dir/qshaderbatchablerewriter.cpp.obj -MF src\shadertools\CMakeFiles\ShaderTools.dir\qshaderbatchablerewriter.cpp.obj.d -o src/shadertools/CMakeFiles/ShaderTools.dir/qshaderbatchablerewriter.cpp.obj -c C:/M/mingw-w64-qt6-shadertools/src/qtshadertools-everywhere-src-6.2.3/src/shadertools/qshaderbatchablerewriter.cpp
2022-02-18T22:58:17.3947771Z In file included from D:/a/msys64/ucrt64/include/c++/11.2.0/bits/stl_algo.h:59,
2022-02-18T22:58:17.3948778Z from D:/a/msys64/ucrt64/include/c++/11.2.0/algorithm:62,
2022-02-18T22:58:17.3949331Z from D:/a/msys64/ucrt64/include/qt6/QtCore/qglobal.h:137,
2022-02-18T22:58:17.3949873Z from D:/a/msys64/ucrt64/include/qt6/QtCore/qatomic.h:41,
2022-02-18T22:58:17.3950406Z from D:/a/msys64/ucrt64/include/qt6/QtCore/qrefcount.h:43,
2022-02-18T22:58:17.3951556Z from D:/a/msys64/ucrt64/include/qt6/QtCore/qbytearray.h:44,
2022-02-18T22:58:17.3952103Z from D:/a/msys64/ucrt64/include/qt6/QtCore/QByteArray:1,
2022-02-18T22:58:17.3953174Z from C:/M/mingw-w64-qt6-shadertools/src/qtshadertools-everywhere-src-6.2.3/src/shadertools/qshaderbatchablerewriter_p.h:44,
2022-02-18T22:58:17.3954945Z from C:/M/mingw-w64-qt6-shadertools/src/qtshadertools-everywhere-src-6.2.3/src/shadertools/qshaderbatchablerewriter.cpp:30:
2022-02-18T22:58:17.3955755Z D:/a/msys64/ucrt64/include/c++/11.2.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
2022-02-18T22:58:17.3956266Z 75 | #include_next <stdlib.h>
2022-02-18T22:58:17.3957123Z | ^~~~~~~~~~
2022-02-18T22:58:17.3957678Z compilation terminated.
also seeing this in several packages :/ happened after we changed the paths where system headers are located.
did update MSYS2 and all GCC today and had the same problem compiling Kage Studio -- then was able to compile again, after adding this line on its make file
-isystem /c/msys64/mingw64/include/c++/12.1.0/
~creek23
No problem on my side after today's update, everything compiles smoothly.
Same here. This is not an issue since a few months ago. It sounds like your MSYS2 installation is borked/altered @creek23, or the Kage build is mingw specific to an older version
I've seen it from time to time crop up in CI, so I'm wondering if some part of it is not deterministic.
I have the same problem as OP while trying to build Nazara Engine using xmake. Somewhere in the build of a component of the engine:
[ 4%]: ccache compiling.debug src\NZSL\Ast\DependencyCheckerVisitor.cpp
C:\tools\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -c -m64 -g -Wall -Wextra -O0 -std=c++17 -Iinclude -Isrc -DNZSL_BUILD -DNZSL_EFSW -DNZSL_STATIC -isystem C:\Users\<user>\AppData\Local\.xmake\packages\n\nazarautils\2022.06.14\0e75f3a725c8498681f075ab1b7fcb52\include -isystem C:\Users\<user>\AppData\Local\.xmake\packages\f\fast_float\v3.4.0\3cccad2d196448798966a8755e3c47b7\include -isystem C:\tools\msys64\mingw64\bin\..\include -isystem C:\Users\<user>\AppData\Local\.xmake\packages\f\frozen\1.1.1\e8d179381108473eb783e2bd3f630d84\include -isystem C:\Users\<user>\AppData\Local\.xmake\packages\o\ordered_map\v1.0.0\a7452f3a25c944a286f7d26b27002568\include -isystem C:\Users\<user>\AppData\Local\.xmake\packages\e\efsw\1.1.0\f46bbe4d14c8410b9047e33567f1c60b\include -Wno-subobject-linkage -Og -Wa,-mbig-obj -o build\.objs\nzsl\mingw\x86_64\debug\src\NZSL\Ast\DependencyCheckerVisitor.cpp.obj src\NZSL\Ast\DependencyCheckerVisitor.cpp
checking for flags (-MMD -MF) ... ok
checking for flags (-fdiagnostics-color=always) ... ok
error: In file included from C:/tools/msys64/mingw64/include/c++/12.1.0/bits/stl_algo.h:69,
from C:/tools/msys64/mingw64/include/c++/12.1.0/functional:64,
from C:\Users\<user>\AppData\Local\.xmake\packages\n\nazarautils\2022.06.14\0e75f3a725c8498681f075ab1b7fcb52\include/Nazara/Utils/Algorithm.hpp:12,
from C:\Users\<user>\AppData\Local\.xmake\packages\n\nazarautils\2022.06.14\0e75f3a725c8498681f075ab1b7fcb52\include/Nazara/Utils/Bitset.hpp:11,
from include/NZSL/Ast/DependencyCheckerVisitor.hpp:10,
from src\NZSL\Ast\DependencyCheckerVisitor.cpp:5:
C:/tools/msys64/mingw64/include/c++/12.1.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
error: execv(xmake build --verbose) failed(-1)
=> install nzsl 2022.07.02 .. failed
error: install failed!
The problem comes from the path C:\tools\msys64\mingw64\bin\..\include
being send to gcc with -isystem
, which makes #include_next
fails (I removed isystem
by modifying xmake for that specific path and everything works).
Since the changes in https://github.com/msys2/MINGW-packages/pull/10634, all "system header" are in that path, instead of being in their own path. If a dependecy have their includes into C:\tools\msys64\mingw64\bin\..\include
directly, and if isystem
is required to avoid warnings from that dependency, isystem
will be added to the whole directory.
The gcc issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 is closed as "wontfix", so I do not see what can be done apart from reverting https://github.com/msys2/MINGW-packages/pull/10634.
Any thought on that ?
EDIT: I have to test adding a -isystem C:/tools/msys64/mingw64/include/c++/12.1.0/
. Anyway, if that trick works, I think we cannot simply ask xmake and the like to add that line everywhere it would be needed.
https://github.com/NazaraEngine/NazaraEngine/runs/7370474642?check_suite_focus=true
CI broke again, this time with a CMake package (assimp)
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.
@lazka @Biswa96 Just a friendly reminder that this issue exists and is a bit annoying, so when you have time to review the few last comments ^^.
MSYS2 now uses the same layout as Linux distros (Arch Linux to be specific). So either the build systems pass wrong options to the compiler or the compiler handles them incorrectly. Do you have an idea whose fault is it?
According to https://packages.ubuntu.com/jammy/amd64/libstdc++-12-dev/filelist and https://archlinux.org/packages/core/x86_64/gcc/,
stdlib.h
(and other standard headers) is in /usr/include/c++/12/stdlib.h
or /usr/include/c++/12/tr1/stdlib.h
, which is not common include dir /usr/include
, so no problem.
On msys2 according to https://packages.msys2.org/package/mingw-w64-x86_64-headers-git?repo=mingw64,
stdlib.h
(and other standard headers) is in /mingw64/include/stdlib.h
, which is the common include dir, so problems.
So no, the layout is definitely not the same !
EDIT: This is wrong, see later.
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
You are right for arch linux. And even for ubuntu https://packages.ubuntu.com/jammy/amd64/libc6-dev/filelist.
So I do not understand why everything works for ubuntu but not when using msys2, even if the project and compiles option are the same...
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.
I guess the path is hard coded somewhere in the build system. Some days ago I notified the Jetbrains team and they updated CLion because it used to validate a Mingw install by detecting the include folder presence. Just my 2cent suggestion for you guys, I hope you sort this out, gl.
Here's the command line:
> D:\a\_temp\msys64\mingw64\bin\x86_64-w64-mingw32-g++ -c -m64 -std=c++11 -isystem D:\a\NazaraEngine\xmake-global\.xmake\packages\a\assimp\v5.2.4\0b973729606a40aab7f2fb4696cf8a63\include -isystem D:\a\_temp\msys64\mingw64\bin\..\include -o D:\a\_temp\msys64\tmp\.xmake\220719\_9FBCAB64B619410AA5B53DAE28D84EC2.o D:\a\_temp\msys64\tmp\.xmake\220719\_9FBCAB64B619410AA5B53DAE28D84EC2.cpp
I guess the issue arise from the usage of -isystem D:\a\_temp\msys64\mingw64\bin\..\include
?
After updating MSYS2 this morning, I cannot compile my app any more, getting this error: