search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.27k stars 1.22k forks source link

gcc seems broken #10761

Open omichel opened 2 years ago

omichel commented 2 years ago

After updating MSYS2 this morning, I cannot compile my app any more, getting this error:

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>
      |               ^~~~~~~~~~
Biswa96 commented 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.

omichel commented 2 years ago

OK, thank you for the quick reply!

class101 commented 2 years ago

@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

lazka commented 2 years ago

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

lazka commented 2 years ago

Please try again now.

omichel commented 2 years ago

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>
      |               ^~~~~~~~~~
lazka commented 2 years ago

thanks, yeah, something is still off.

I can't reproduce though.

lazka commented 2 years ago

@class101 those relocations are on purpose, see #10634

Biswa96 commented 2 years ago

@omichel Please provide the project link and details about how to compile it.

omichel commented 2 years ago

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.

class101 commented 2 years ago

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 image

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)
class101 commented 2 years ago

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 :)

SirLynix commented 2 years ago

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

Biswa96 commented 2 years ago

@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 commented 2 years ago

@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?

Biswa96 commented 2 years ago

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.

SirLynix commented 2 years ago

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.

lock042 commented 2 years ago

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.

waruqi commented 2 years ago

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
Biswa96 commented 2 years ago

@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
Biswa96 commented 2 years ago

@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.

lock042 commented 2 years ago

@Biswa96 : yes I use crossroad that uses Msys2. The CI failed after Msys2 update.

Biswa96 commented 2 years ago

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.

omichel commented 2 years ago

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;
}
Biswa96 commented 2 years ago

/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

omichel commented 2 years ago

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 commented 2 years ago

@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.

Biswa96 commented 2 years ago

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/

waruqi commented 2 years ago

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?

waruqi commented 2 years ago

@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.

lock042 commented 2 years ago

Biswa96

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

Biswa96 commented 2 years ago

../meson.build:227:0: ERROR: C shared or static library 'm' not found

libm should be ignored in Win32 platform.

jeremyd2019 commented 2 years ago

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

jeremyd2019 commented 2 years ago

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.
revelator commented 2 years ago

also seeing this in several packages :/ happened after we changed the paths where system headers are located.

creek23 commented 2 years ago

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

omichel commented 2 years ago

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

class101 commented 2 years ago

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

lazka commented 2 years ago

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

ImperatorS79 commented 2 years ago

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.

SirLynix commented 2 years ago

https://github.com/NazaraEngine/NazaraEngine/runs/7370474642?check_suite_focus=true

CI broke again, this time with a CMake package (assimp)

revelator commented 2 years ago

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.

ImperatorS79 commented 2 years ago

@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 ^^.

mati865 commented 2 years ago

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?

ImperatorS79 commented 2 years ago

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.

1480c1 commented 2 years ago 
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

ImperatorS79 commented 2 years ago

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...

SirLynix commented 2 years ago

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.
class101 commented 2 years ago

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.

SirLynix commented 2 years ago

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?