I am trying to compile the ANTLR4 runtime sources
with GCC compiler and MinGW libraries. Is that
possible.
My development environment :
Windows 10, CodeBlocks, GCC, MinGW libraries
Compilation stops with the following error :
error: 'mutex' in namespace 'std' does not name a type
Kind regards
Pier Tilma
The MinGW version that comes with Code::Blocks us much too old.
Use a more up to date version of MinGW-w64.
For example the one from: https://winlibs.com/ (instructions for Code::Blocks are on the site).
Thanks Sanders,
Using an up-to-date MingW version doesn't give me anymore the
error: 'mutex' in namespace 'std' does not name a type.
But now I ran into another problem :
When crosscompiling the ANTLR4 runtime sources for windows on Linux I
get the following error :
/src/atn/ATNSimulator.cpp:17:21: error: definition of static data member ‘antlr4::atn::ATNSimulator::ERROR’ of dllimport’d class
My configuration :
os : Ubuntu (Linux 5.15.0-52-generic x86_64),
compiler : x86_64-w64-mingw32-gcc (9.3 posix),
antlr4 : runtime sources 4.11.1
Regards pstilma
Related
I have a project, which cannot be compiled by a fellow, due to an unknown call to a method from the std library.
I suspect that it's due to the fellow's g++ version (9.4.2) because the function was added in the std 20 standard. To test if that is the case I installed g++-9 (Version 9.5.0) and pointed the /usr/bin/g++ symbolic link to g++-9 and stumbled upon another issue (the question).
When I run
$ g++-9 -std=c++20
g++-9: error: unrecognized command line option ‘-std=20’; did you mean ‘-std=c2x’?
g++-9: fatal error: no input files
compilation terminated.
I get an error stating, that the std standard version 20 is unknown.
But when I try to generate the build files for an cmake project with the following line in the CMakeLists.txt:
target_compile_features(${PROJECT_NAME}
PUBLIC
cxx_std_20
)
I get no error. But when replacing the 20 with a 23:
target_compile_features(${PROJECT_NAME}
PUBLIC
cxx_std_23
)
I get the error
CMake Error at CMakeLists.txt:74 (target_compile_features):
target_compile_features The compiler feature "cxx_std_23" is not known to
CXX compiler
"GNU"
version 9.5.0.
Why is the C++20 standard unknown to g++, but known, when generating build files with cmake?
This is some sort of follow up Question:
When I try to compile my project I get the error:
error: ‘std::stringstream’ {aka ‘class std::__cxx11::basic_stringstream<char>’} has no member named ‘view’
and view was added in c++20. Can it be, that view was jet not added in c++2a?
Well... if your compiler is GCC 9.5.0, the reason why CMake says it doesn't know about C++23 is because... it doesn't?
https://en.cppreference.com/w/cpp/compiler_support
The only thing that cppreference.com's compiler support table says that GCC v9 "knows" about C++23 is "Narrowing contextual conversions in static_assert and constexpr if"
And the reason why you get "g++-9: error: unrecognized command line option ‘-std=20’; did you mean ‘-std=c2x’?" for GCC 9.5.0 is probably just because C++20 support wasn't fully implemented yet. Again, look at the compiler support table in cppreference.com. There are lots of core language features and library features for C++20 that GCC didn't implement until version 10 (some even in version 9-13 Ex. "Atomic Compare-And-Exchange with padding bits")
So just do what it told you to do and take what you get, accepting that not all of the C++20 features will be available in GCC 9.5.0.
Or upgrade you compiler :P
The reason why it works with CMake's target_compile_features(... cxx_std_20) is because... CMake handles it.
See Modules/Compiler/GNU-C.cmake:
if(CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 9.1)
set(CMAKE_C23_STANDARD_COMPILE_OPTION "-std=c2x")
set(CMAKE_C23_EXTENSION_COMPILE_OPTION "-std=gnu2x")
endif()
and Modules/Compiler/GNU-CXX.cmake:
elseif(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 8.0)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-std=c++2a")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-std=gnu++2a")
endif()
The name of the option for standard C++20 up to GCC 9 is -std=c++2a. According to man gcc:
c++2a
The next revision of the ISO C++ standard, planned for 2020. Support is highly experimental, and will almost certainly change in incompatible ways in future releases.
So not all features can be expected to be in there.
GCC has a tradition of providing aliases for the not yet released standards or those with incomplete support. GCC 9 only knows c++2a and that became an alias for c++20 with GCC 10.
CMake can handle this. When in doubt what CMake uses as standard (or any other option), take a look in the build directory in flags.make or build.ninja (depending on which generator you're using).
I am running clang-tidy checks using cmake version 3.20.0-rc1 on Windows 10.
My project builds using GNU 8.3.0.
Sadly I get the error
error: 'cstddef' file not found [clang-diagnostic-error]
#include <cstddef>
clang-tidy info:
LLVM (http://llvm.org/):
LLVM version 12.0.0
Optimized build.
Default target: i686-pc-windows-msvc
Host CPU: skylake
[clang-diagnostic-error] is basically a compiler error coming from the clang backend.
Clang-tidy needs an AST (abstract syntax tree) - your code has to be compileable by clang compiler in order to generate an AST. Only then will clang-tidy analyze your code.
Get your code to compile by clang instead of GCC and you should find the source of your problem.
I am trying to generate a shared native library using cmake. the contents of this library are nothing more than native functions that will later be used in Unity. that is why the functions have the extension __declspec (dllexport) so that in the Unity section they can be called with dllImport.
My problem comes when I try to compile that library in cmake. I am using Ninja as compiled and cross-compiled with Android toolchain. The problem is that it tells me:
../InnovaeInterface/include/Camara.h:7:2: error: unknown type name '_declspec'
_declspec(dllexport) CameraUtils::Calibration* createCamara(void);
^
../InnovaeInterface/include/Camara.h:7:22: error: expected ';' after top level declarator
_declspec(dllexport) CameraUtils::Calibration* createCamara(void);
^
The truth is that I have no idea where to throw. I hope you help me.
I'm trying to build Tensorflow on Windows 7 x64 using the guide published here, however, when invoking MSBuild to build TensorFlow (step 4), I get a "Build FAILED" message followed by several errors.
The first:
CUSTOMBUILD : CMake error : CMake can not determine linker language for target: grpc [grpc.vcxproj]
CUSTOMBUILD : CMake error : CMake can not determine linker language for target: grpc_unsecure [grpc.vcxproj]
CUSTOMBUILD : CMake error : CMake can not determine linker language for target: cares [grpc.vcxproj]
does not make sense because within my grpc CMakelists.txt I have the following defined:
set(PACKAGE_NAME "grpc")
project(${PACKAGE_NAME} C CXX)
The other errors all involve source directories not containing a CMakelists.txt file:
CUSTOMBUILD : CMake error : The source directory "C:/tf-dev/local_repos/cub-1.6.4" does not appear to contain CMakeLists.txt. [cub.vcxproj]
which occurs for the following external projects:
cub
farmhash
fft2d
gemmlowp
gif
highwayhash
jpeg
lmdb
However, the Tensorflow build guide does not make any reference to creating additional CMakelists.txt for the externally added projects. Any idea where I might be going wrong? Thanks.
During building a c++ source code (configured with cmake gui) with mingw under MSYS gives following error while trying to "Linking C shared library":
Unrecognized option "--enable-new-dtags"
How can i solve this issue?
Likely --enable-new-dtags is supported only on ELF targets. For example there's a patch for Python3 distutils which sets this flag conditionally on the target platform: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-python3/0260-MINGW-compiler-enable-new-dtags.patch . You should make sure that this flag isn't specified explicitly somewhere in your project.