Code::Blocks Forums
User forums => General (but related to Code::Blocks) => Topic started by: everSome on November 11, 2022, 10:14:29 am
-
Is it reasonable to even be trying to do this? I'm using the 15.0.4 version of the clang and clang++ compiler drivers against the r13000 version of CodeBlocks. Any known gotchas? So far I've had to fix wxWidgets 3.2.1 since clang generates the following predefines:
#define __GNUC__ 4
#define __GNUC_MINOR__ 2
-
Just to clarify, I'm experimenting with the MSYS2 binary package obtained via:
pacman -S --needed mingw-w64-ucrt-x86_64-clang
that ties into the gcc toolchain as I understand it without going the full llvm route, Could be wrong on this though.
-
Any ideas on how to rectify this error:
-------------- Build: sdk in Code::Blocks wx3.2.x (64 bit) (compiler: CLANG MSYS2 UCRT64 Compiler)---------------
.
.
.
clang++.exe -Wall -std=gnu++11 -m64 -O3 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DwxUSE_UNICODE -D_WIN64 -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -m64 -Wno-unused-local-typedefs -Wno-deprecated-declarations -march=native -Wno-unused-command-line-argument -Wno-ignored-attributes -Wno-unused-but-set-variable -IC:\msys64\home\NateJoe\wxWidgets\normal\wxWidgets-3.2.1\include -IC:\msys64\home\NateJoe\wxWidgets\normal\wxWidgets-3.2.1\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\include -Isdk\mozilla_chardet\include -Isdk\mozilla_chardet\include\mfbt -Isdk\mozilla_chardet\include\nsprpub\pr\include -Isdk\mozilla_chardet\include\xpcom -Isdk\mozilla_chardet\include\xpcom\base -Isdk\mozilla_chardet\include\xpcom\glue -Isdk\scripting\bindings -IC:\msys64\ucrt64\include -c C:\msys64\home\NateJoe\CodeBlocks\codeblocks-code-r13000-trunk\src\sdk\cbeditor.cpp -o .objs32_64\sdk\cbeditor.o
.
.
.
In file included from C:\msys64\home\NateJoe\CodeBlocks\codeblocks-code-r13000-trunk\src\sdk\cbcolourmanager.cpp:10:
In file included from include/sdk_precomp.h:13:
In file included from include/sdk_common.h:127:
include/logmanager.h:40:28: warning: passing an object of reference type to 'va_start' has undefined behavior [-Wvarargs]
va_start(arg_list, msg);
^
include/logmanager.h:37:39: note: parameter of type 'const wxString &' is declared here
inline wxString F(const wxString &msg, ...)
^
C:\msys64\home\NateJoe\CodeBlocks\codeblocks-code-r13000-trunk\src\sdk\cbcolourmanager.cpp:18:47: error: explicit specialization of 'instance' after instantiation
template<> ColourManager* Mgr<ColourManager>::instance = nullptr;
^
include/manager.h:206:18: note: implicit instantiation first required here
static MgrT *instance;
^
C:\msys64\home\NateJoe\CodeBlocks\codeblocks-code-r13000-trunk\src\sdk\cbcolourmanager.cpp:19:38: error: explicit specialization of 'isShutdown' after instantiation
template<> bool Mgr<ColourManager>::isShutdown = false;
^
include/manager.h:207:17: note: implicit instantiation first required here
static bool isShutdown;
^
1 warning and 2 errors generated.
Process terminated with status 1 (2 minute(s), 33 second(s))
-
Just to clarify, I'm experimenting with the MSYS2 binary package obtained via:
pacman -S --needed mingw-w64-ucrt-x86_64-clang
that ties into the gcc toolchain as I understand it without going the full llvm route, Could be wrong on this though.
Since it install an llvm package I have no idea why you think it does not go the full llvm route.
Me, I would try GCC under UCRT64 first because that at least will verify CB builds under UCRT64.
Tim S.
-
FYI, I'm using a version of CodeBlocks, r13019 to be exact, build with:
$ g++ --version
g++.exe (Rev6, Built by MSYS2 project) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
to be exact, to utilize clang in compiling CodeBlocks. Here's the the pertinent output. I don't even get any warnings compiling it.
-------------- Build: sdk in Code::Blocks wx3.2.x (64 bit) (compiler: GNU GCC MSYS2 UCRT64 Compiler)---------------
.
.
.
g++.exe -Wall -std=gnu++11 -m64 -O3 -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DwxUSE_UNICODE -D_WIN64 -Woverloaded-virtual -DEXPORT_LIB -DEXPORT_EVENTS -DWXMAKINGDLL_SCI -m64 -Wno-unused-local-typedefs -Wno-deprecated-declarations -march=native -IC:\msys64\home\NateJoe\wxWidgets\normal\wxWidgets-3.2.1\include -IC:\msys64\home\NateJoe\wxWidgets\normal\wxWidgets-3.2.1\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Iinclude -Iinclude\tinyxml -Iinclude\scripting\include -Isdk\mozilla_chardet\include -Isdk\mozilla_chardet\include\mfbt -Isdk\mozilla_chardet\include\nsprpub\pr\include -Isdk\mozilla_chardet\include\xpcom -Isdk\mozilla_chardet\include\xpcom\base -Isdk\mozilla_chardet\include\xpcom\glue -Isdk\scripting\bindings -IC:\msys64\ucrt64\include -c C:\msys64\home\NateJoe\CodeBlocks\codeblocks-code-r13019-trunk\src\sdk\cbcolourmanager.cpp -o .objs32_64\sdk\cbcolourmanager.o
-
Note the following excerpts from MSYS2 documentation:
Name Prefix Toolchain Architecture C Library C++ Library
MINGW64 /mingw64 gcc x86_64 msvcrt libstdc++
UCRT64 /ucrt64 gcc x86_64 ucrt libstdc++
CLANG64 /clang64 llvm x86_64 ucrt libc++
.
GCC vs LLVM/Clang:
.
GCC based environments:
.
While there also exists a Clang package in the MINGW environments, that one still uses the GNU linker and the GNU C++ library.
.
LLVM/Clang based environments:
.
Only uses LLVM tools, LLD as a linker, LIBC++ as a C++ standard library.
Also note the following from the README.md file at
https://github.com/mstorsjo/llvm-mingw
which is where Mingw-w64 seems to get it's clang/llvm implementations:
Clang on its own can also be used as compiler in the normal GNU binutils based environments though, so the main difference lies in replacing binutils with LLVM based tools.
-
This problem may well involve a non-standard usage or a posix variant (if such things exist) of c++ templates that gcc supports and clang doesn't. In trying to find out where the bodies therein are buried, I've come to the conclusion that they've all been cremated! Welcome to the fun world of C++ Template Metaprogramming. This will take awhile (at least for me).