CB C++ Issue with GNU C++ 17 (ISO)

[jmClifford]

Hi. I have a "to-do list" projects (compliments of OttoBotCode on the web).  It works fine when I have no Project->Build Options->Compiler setting Flags select.  However when I select say GNU C++ 17 ISO, the compiler errors.

A part of the build messages;
wx_pch_h_gch: not used because `__cpp_static_assert' defined as ` 201411' not ` 200410' [-Winvalid-pch]|

C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\bits\fs_path.h||In member function 'std::filesystem::__cxx11::path& std::filesystem::__cxx11::path::operator/=(const std::filesystem::__cxx11::path&)':|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\bits\fs_path.h|237| error:      no match for 'operator!=      (operand types are 'std::filesystem::__cxx11::path' and 'std::filesystem::__cxx11::path')|
C:\Program Files\CodeBlocks\MinGW\lib\gcc\x86_64-w64-mingw32\8.1.0\include\c++\bits\stl_pair.h|456|note: candidate: 'template<class _T1, class _T2> constexpr bool std::operator!=(const std::pair<_T1, _T2>&, const std::pair<_T1, _T2>&)'|
C:\Program Files\CodeBlocks\MinG

Also, what is the difference between Project ->Build Options    and   Setting->Compiler->Global Compiler Settings.
The descriptions seem to be seemly the same.

Regards JC.......

[Grit Clef]

Also, what is the difference between Project ->Build Options    and   Setting->Compiler->Global Compiler Settings.
The descriptions seem to be seemly the same.

Just as the "Global" means, Global Compiler Settings will make effects on every project in your CodeBlocks, every source file. Instead, Build Options will only influence that  project, each project can have different options.
I suggest you updating your compiler, not using MinGW 8.1.0!

[jmClifford]

Hi.  Would a more recent compiler version fix the compiling issue ??
This upgrade seems a difficult process.
And where do you locate the correct "compile" files and what version to choose??

Regards JC.......

[nenin]

Hi.  Would a more recent compiler version fix the compiling issue ??
This upgrade seems a difficult process.
And where do you locate the correct "compile" files and what version to choose??
Regards JC.......

Recent mingw-w64 gcc are  definetly better in standard implementations.
Fresh one can be found here:
https://winlibs.com/
and here:
https://github.com/niXman/mingw-builds-binaries/releases
In my humble opinion proper version is
x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z
or
i686-13.2.0-release-win32-dwarf-ucrt-rt_v11-rev0.7z
which using ucrt and native win32 threads in standard libs.

[jmClifford]

and here:
https://github.com/niXman/mingw-builds-binaries/releases
In my humble opinion proper version is
x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z

Thank you for the above information.  I have downloaded a
x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev1.7z unpacked it and loaded to
C:\Program Files\CodeBlocks\MinGW.
This is the very original location.  The compiler error for C++ 17 (ISO) is gone.  But I now have a run time error involving wx_Widgets.  This is attached (I hope) and is a Entry Point Not Found in a wx*.dll.
I am asking if my approach on simpling replacing the old compiler location with the new is OK, and to remove the run time error I possible need to re-compile the wx_Widgets libraries as a I have done previously. ?? This compile took some time.!

Regards JC......

[nenin]

The compiler error for C++ 17 (ISO) is gone.  But I now have a run time error involving wx_Widgets.  This is attached (I hope) and is a Entry Point Not Found in a wx*.dll.
I am asking if my approach on simpling replacing the old compiler location with the new is OK, and to remove the run time error I possible need to re-compile the wx_Widgets libraries as a I have done previously. ?? This compile took some time.!

Regards JC......

At my experience all linked C++ dlls should be build with the same compiler you are using for your application. So, you have to build you version of the wxWidgets or to use the same compiler as was used for these dlls.
Also there are strong reasons to avoid  install mingw in path with spaces.

[Grit Clef]

......
I am asking if my approach on simpling replacing the old compiler location with the new is OK, and to remove the run time error I possible need to re-compile the wx_Widgets libraries as a I have done previously. ?? This compile took some time.!

Regards JC......

As I experienced, you can try adding -jx to make command, where x represents the thread number of gcc called simultaneously, to take full advantages of CPU and speed up compilation. I can ensure that it'll take no more than 20 minutes to finish compiling wxWidgets.

[jmClifford]

Hi. Thanks for the help.
I have MinGW 13.2 working (after 2 X 1 hour builds; release and debug).
The "To_Do" program operates even without nominating GNU C++ 17.
I can access the items in the <filesystem> now, which I was failing on before.  This is mainly file/folder exits().

I will consider the -jx option (wrt threads) next time.  Or maybe sooner, since I am interested in this for myself (my programming).

Regards JC......

[Markelov69]

Hi.  Would a more recent compiler version fix the compiling issue ??
This upgrade seems a difficult process.
And where do you locate the correct "compile" files and what version to choose??
Regards JC.......

Recent mingw-w64 gcc are  definetly better in standard implementations.
Fresh one can be found here:
https://winlibs.com/
and here:
https://github.com/niXman/mingw-builds-binaries/releases/web
In my humble opinion proper version is
x86_64-13.2.0-release-win32-seh-ucrt-rt_v11-rev0.7z
or
i686-13.2.0-release-win32-dwarf-ucrt-rt_v11-rev0.7z
which using ucrt and native win32 threads in standard libs.

Thank you!

[Miguel Gimenez]

Spam reported to moderator.