I am compiling a static library (Rive in this case) with iterator debug level of 2, to be compatible with all my other static libs in this project. The toolset is LLVM clang on Windows, targeting x64.
Side note: The Rive project uses a different build system (premake5) than the others I have compiled, which have used cmake.
I am getting an error during compile #error _ITERATOR_DEBUG_LEVEL > 1 is not supported in release mode.. However, from what I can tell, I am NOT compiling in release mode. Why might I be getting the error about "release mode"?
Here is an example compiler command:
clang++ -MMD -MP -D_USE_MATH_DEFINES -DDEBUG -D_ITERATOR_DEBUG_LEVEL=2 -I../include -m64 -g -std=c++17 -Wall -fno-exceptions -fno-rtti -MTd -o \"obj/debug/cubic_asymmetric_vertex_base.o\" -MF \"obj/debug/cubic_asymmetric_vertex_base.d\" -c \"../src/generated/shapes/cubic_asymmetric_vertex_base.cpp\"",...)
From what I can tell, -g is generating debug symbols and -MTd specifies debug static library. Why is the error telling me I'm in release mode?
The following two things combined solved this problem for me:
Pass in the flag _DEBUG as well as DEBUG
Run make using PowerShell instead of bash
This allowed me to compile a static library in debug mode with _ITERATOR_DEBUG_LEVEL of 2.
Related
I am trying to set up debugging with VScode for nvc++ on Ubuntu 20.04
I am using CMake to build my program that is using openmp and have cmake-tools as vscode extensions.
My c++ project is well setup with CMake, GCC, and openMP. After installing HPC SDK and setting up the nvcc and nvc++ compilers, when I switch the tools, the build is failing, complaining about openMP. By default VScode is using nvcc -fopenmp -v -fPIE -std=gnu99 -o outputfile.o. When I compile my code in the terminal window with just a simple addition of -Xcompiler flag such as nvcc -Xcompiler -fopenmp -v -fPIE -std=gnu99 -o outputfile.o it is working. But how do I set that up in vscode?
Below is the exact error I am getting:
/opt/nvidia/hpc_sdk/Linux_x86_64/22.5/compilers/bin/nvcc -fopenmp -v -fPIE -std=gnu99 -o CMakeFiles/cmTC_568be.dir/OpenMPTryFlag.c.o -c /directory/program/build/CMakeFiles/FindOpenMP/OpenMPTryFlag.c
nvcc fatal : Value ‘gnu99’ is not defined for option ‘std’
Any help is would be appreciated!
I'm writing a lot of cross platform C++, and am trying to unify my build process between platforms (primarily targeting Windows and Mac at the moment, potentially mobile in the future.) In addition to our normal CI builds, we are built from source as part of an extremely large C++ project's build and consequently have quite a complex toolchain.
Right now, my code compiles cleanly on Windows using CMake to generate a Visual Studio project and then using clang-cl to compile. Similarly, we are using CMake to generate a ninja project and then clang to compile.
We are a Windows shop, and I would like to leverage WSL to set up cross compilation, which should allow us to use the same ninja project to target both supported platforms and modify in the future.
I am able to successfully compile a simple hello world exe program using clang from my wsl-hosted bash terminal. In order to do this, I had to provide a large amount of options to clang as well as move a significant amount of Win10 SDK libraries to my build environment for clang to build and link against.
Here are the two commands I run to successfully produce helloworld.exe:
Compiling:
clang -target i686-pc-win32 -fms-compatibility-version=19 -fms-extensions -fdelayed-template-parsing -fexceptions -mthread-model posix -fno-threadsafe-statics -Wno-msvc-not-found -DWIN32 -D_WIN32 -D_MT -D_DLL -Xclang -disable-llvm-verifier -Xclang '--dependent-lib=msvcrt' -Xclang '--dependent-lib=ucrt' -Xclang '--dependent-lib=oldnames' -Xclang '--dependent-lib=vcruntime' -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -U__GNUC__ -U__gnu_linux__ -U__GNUC_MINOR__ -U__GNUC_PATCHLEVEL__ -U__GNUC_STDC_INLINE__ -I/mnt/d/source/windeps/LLVM/include -I/mnt/d/source/windeps/MSVC/14.22.27905/include -I/mnt/d/source/windeps/ucrt -I/mnt/d/source/windeps/shared -I/mnt/d/source/windeps/winrt -c hello.cc -o hello.o
Linking:
clang -fuse-ld=lld-link.exe -target i686-pc-win32 -Wl,-machine:x86 -fmsc-version=1923 -o hello.exe hello.o -L/mnt/d/source/windeps/MSVC/14.22.27905/lib/x86/msvcrt.lib -nostdlib -lmsvcrt -Wno-msvc-not-found
Naturally, I have attempted to express this first command via my CMake toolchain:
add_compile_options(
-W
-Wall
-std=c++17
-stdlib=libc++
-fcoroutines-ts
-fms-extensions
-fdelayed-template-parsing
-fexceptions
-fdeclspec
-mthread-model posix
-fno-threadsafe-statics
-Wno-msvc-not-found
-DWIN32
-D_WIN32
-D_MT
-D_DLL
-Xclang
-disable-llvm-verifier
# These are commented out currently, but I have linked them to the proper CMakeList
# -Xclang '--dependent-lib=msvcrt'
# -Xclang '--dependent-lib=ucrt'
# -Xclang '--dependent-lib=oldnames'
# -Xclang '--dependent-lib=vcruntime'
-D_CRT_SECURE_NO_WARNINGS
-D_CRT_NONSTDC_NO_DEPRECATE
-U__GNUC__
-U__gnu_linux__
-U__GNUC_MINOR__
-U__GNUC_PATCHLEVEL__
-U__GNUC_STDC_INLINE__
-I/mnt/d/source/windeps/LLVM/include
-I/mnt/d/source/windeps/MSVC/14.22.27905/include
-I/mnt/d/source/windeps/um
-I/mnt/d/source/windeps/ucrt
-I/mnt/d/source/windeps/shared
-I/mnt/d/source/windeps/winrt
)
This is throwing an error from within the ucrt library when one of our files (event_logger.cpp) does #include <array>.
In file included from src/client/services/src/event_logger.cpp:10:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/array:6:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/algorithm:6:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/xmemory:8:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/limits:8:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/cwchar:8:
In file included from /mnt/d/source/windeps/MSVC/14.22.27905/include/cstdio:8:
In file included from /mnt/d/source/windeps/ucrt/stdio.h:13:
/mnt/d/source/windeps/ucrt/corecrt_wstdio.h:581:9: error: use of undeclared identifier '__crt_va_end'
__crt_va_end(_ArgList);
^
/mnt/d/source/windeps/ucrt/corecrt_wstdio.h:597:9: error: use of undeclared identifier '__crt_va_start_a'
__crt_va_start(_ArgList, _Locale);
^
/mnt/d/source/windeps/MSVC/14.22.27905/include/vadefs.h:156:99: note: expanded from macro '__crt_va_start'
#define __crt_va_start(ap, x) ((void)(__vcrt_assert_va_start_is_not_reference<decltype(x)>(), __crt_va_start_a(ap, x)))
Because of this behavior, I'm suspicious that perhaps we're not using libc++ as indicated by the -stdlib flag. I'm also not sure how to correct this, as this seems to be kind of a newer process and there's not a ton of documentation in the wild yet. Any advice is appreciated.
Ubuntu 17.10
GCC Version: 5.4
Bazel Version: 0.9.0
TensorFlow: r1.5
CUDA 8.0 / cuDNN 6 / GTX 1080 Ti
How do I make Bazel use gcc for building TensorFlow from source?
While building, its running into compiler errors like:
error: 'errno' was not declared in this scope
while (nanosleep(&ts, &ts) != 0 && errno == EINTR) {}
Setting --verbose_failures flag, it shows that its not using /usr/bin/gcc-5 or /usr/bin/gcc for compiling
external/local_config_cuda/crosstool/clang/bin/crosstool_wrapper_driver_is_not_gcc -U_FORTIFY_SOURCE '-D_FORTIFY_SOURCE=1' -fstack-protector -fPIE -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -ffunction-sections -fdata-sections -g0 -DGEMMLOWP_ALLOW_SLOW_SCALAR_FALLBACK '-march=native' '-std=c++11' -g0 -MD -MF
Searching online, I found that the path to gcc and CC, CXX variables must be set in tools/cpp/CROSSTOOL. But where exactly is tools/cpp/CROSSTOOL?? How do I force bazel to use gcc-5?
I know next to nothing about cuda and tensorflow, but tensorflow doesn't use the same C++ toolchain that bazel autoconfigures when compiling with cuda, so the CC env variable trick won't work. The file crosstool_wrapper_driver_is_not_gcc is just a shell wrapper that could in theory still call your gcc (or it will be cuda). I'd run bazel with --subcommands to see the complete invocation of the failing action, then reproduce without bazel, and then go from there.
When I build a Release C++ project in NetBeans, it automatically configures it with the -O2 option.
I don't see anywhere in the compiler options where I can override this value. I know it's set to -O2 because I can see the cmdlines it uses in the Build window: g++ -O2 ...
If I add -O1 into the "Additional Otions" within the compiler settings it doesn't honour it because the cmdline now becomes g++ -O1 -O2 ... and so the -O2 supersedes my own setting.
So, where in the IDE can I set the -O optimization level compile setting?
I am using GNU compile tools on Linux if that makes any difference.
I finally found the solution by exploring a bit more. In the dialog from the OP there is the option, 'Development Mode' which is currently set to 'Release'. There are a number of options under there and each of those correspond to different optimization levels and/or debug output compile flags:
No Flags -c
Debug -c -g
Performance Debug -c -g -O
Test Coverage -g -c
Diagnosable Release -c -g -O2
Release -c -O2
Performance Release -c -O3
Although there doesn't seem to be an option for -O1, that's basically the intended way for you to select different optimization levels in NetBeans.
Please look at the nbproject/Makefile-Release.mk file.
nekto#ubuntu:~/host/ex/dt-netbeans-samples-cpp-Welcome$ grep -r O2 *
nbproject/Makefile-Release.mk: $(COMPILE.cc) -O2 -MMD -MP -MF "$#.d" -o ${OBJECTDIR}/welcome.o welcome.cc
It looks like the -O2 option presence in the Release configuration is the default and unchangeable, however you always can create your own build configuration (and you did as I see).
Each build configuration has its own nbproject/Makefile-<configuration name>.mk file, which contains following lines:
# CC Compiler Flags
CCFLAGS=-O1
CXXFLAGS=-O1
I've created a new configuration, made it active, and set the -O1 option above from the NetBeans properties pop-up window, C++ Compiler -> Additional Options, and my compilation line didn't contain the -O2 option. My Additional Options panel is below:
I'm using MinGw on Windows 7. The following simple program compiles fine, but the linker complains and I do not understand what's wrong:
#include <iostream>
#include <vector>
using namespace std;
int main()
{
std::vector<int> iv;
iv.push_back(7);
cout << iv.back() << endl;
return 0;
}
the compiler/linker messages look as follows:
mingw32-g++.exe -Wall -fexceptions -std=c++0x -Wall -g -std=c++0x -Wall -g -frepo -IC:\cppbuchincludes\include -IG:\Boost -IG:\Users\thomas\cpp\STLUsage\\include -c G:\Users\thomas\cpp\STLUsage\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -o bin\Debug\STLUsage.exe obj\Debug\main.o G:\Boost\stage\lib\libboost_filesystem-mgw45-mt-d-1_45.dll.a G:\Boost\stage\lib\libboost_regex-mgw45-mt-d-1_45.dll.a G:\Boost\stage\lib\libboost_system-mgw45-mt-d-1_45.dll.a G:\Boost\stage\lib\libboost_thread-mgw45-mt-1_45.dll.a G:\Boost\stage\lib\libboost_unit_test_framework-mgw45-mt-d-1_45.dll.a
collect: recompiling G:\Users\thomas\cpp\STLUsage\main.cpp
collect: relinking
collect2: '_ZNSt12_Vector_baseIiSaIiEEC1Ev' was assigned to 'obj\Debug\main.rpo', but was not defined during recompilation, or vice versa
obj\Debug\main.o: In function `vector':
c:/mingw/bin/../lib/gcc/mingw32/4.5.2/include/c++/bits/stl_vector.h:208: undefined reference to `std::_Vector_base<int, std::allocator<int> >::_Vector_base()'
(...and so on...)
I can use templates I defined myself.
I have that MinGw binary from a book and followed the instructions in that book regarding compiler settings. In particular the references to the Boost libs are taken from there.
This must be a simple thing, I just want to make trivial use of the STL.
Edit following the advice given in an answer, I replaced the binary to be used to compile by g++.exe in the Settings -> Compiler and debugging -> toolchain executables dialog, but I'm getting the same error messages (with mingw32-g++.exe now replaced by g++.exe).
Edit (once more) this has to be problem eith the Code::Blocks settings, since compiling using g++ from the command line works just fine.
Use g++ to compile and link the program. mingw32-g++.exe doesn't do that.
FAQ says,
What's the difference between gcc and mingw32-gcc?
The mingw32-gcc, mingw32-g++, etc. binaries exist as an aid to cross development. They are created in a typical build of gcc. They are therefore distributed as the maintainers of GCC meant them to be. The gcc.exe indicates that the binary produces binaries for a target equal to the build, while the mingw32-gcc binary produces binaries to be executed on the mingw32 target.
So I guess the problem is because of mingw32-g++.exe which you're not supposed to use, for normal build.
Try these:
g++ program.cpp //simple build
g++ program.cpp -Wall //build with all warnings enabled
g++ program.cpp -Wall -O2 //enable warnings and optimization level 2
g++ program.cpp -std=c++0x //use C++11 features
Hope that helps.