So this is a followup question to Visual Studio 2015 Update 1, clang error
The error message I'm getting is
clang.exe : error : cannot specify -o when generating multiple output files
Basically, Hans Passant's workaround of disabling precompiled headers did not work for me. I'm still seeing the error. Anybody have any more ideas to work around this?
My VS-generated command line is: -fpic -std=c++1y -fstack-protector -x c++ "Debug\" -Wall -fno-strict-aliasing -ffunction-sections -I "c:\SDKs\VST3 SDK" -I "c:\SDKs\vstsdk2.4" -I "....\JuceLibraryCode" -I "......\JUCE\modules" -g2 -gdwarf-2 -O0 -x c++-header -D "_CRT_SECURE_NO_WARNINGS" -D "WIN32" -D "_WINDOWS" -D "DEBUG" -D "_DEBUG" -D "JUCER_VS2010_78A501D=1" -D "JUCE_APP_VERSION=1.0.0" -D "JUCE_APP_VERSION_HEX=0x10000" -D "_WINDLL" -frtti -fomit-frame-pointer -fdata-sections -fno-ms-compatibility -std=c11 -fexceptions -o "Debug\" -fms-extensions -fno-short-enums
I'm trying to build a C++ JUCE audio plugin in Windows with Clang because I ended up using a good amount of C++14 features when developing it initially on Mac and did not realize that other compilers were a bit more behind in C++ standard support. JUCE applications provide cross platform support by a VS/XCode project file or Makefile generated from the Introjucer/Projucer application. If I set up a new project with the VS2015 Cross-Platform C++ DLL with Clang 3.7 project template, everything compiles fine. But using the JUCE-generated VS project file and then switching the project preferences to use the Clang 3.7 project toolset is where I run into this error.
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 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.
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.
I am trying to use gdb to debug an hdf5 C++ application that I have written. The h5 package that I am using was installed using conda. The command that I am using is:
h5c++ hdf5.cpp
This generates an executable which I then run with gdb as follows:
gdb a.out
gdb launches alright. But when I add breakpoint using:
b 10
or any line number, it gives a message: No line 10 in file "init.c"
When I press run, it runs the whole program at once (which I don't want) and exits. The h5c++ -show command gives the following output:
x86_64-conda_cos6-linux-gnu-c++ -I/i3c/hpcl/sms821/software/tensorflow/anaconda2/include -D_FORTIFY_SOURCE=2 -O2 -g -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/i3c/hpcl/sms821/software/tensorflow/anaconda2/include -fdebug-prefix-map==/usr/local/src/conda/- -fdebug-prefix-map==/usr/local/src/conda-prefix -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_hl_cpp.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_cpp.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5_hl.a /i3c/hpcl/sms821/software/tensorflow/anaconda2/lib/libhdf5.a -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-rpath,/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -L/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib -g -lrt -lpthread -lz -ldl -lm -Wl,-rpath -Wl,/i3c/hpcl/sms821/software/tensorflow/anaconda2/lib
I think this has to do with the compiler the compiler that it is using. I tried replacing x86_64-conda_cos6-linux-gnu-c++ with my native g++ compiler in the h5c++ script but that gives linker error.
Please suggest how should make my h5 application work with gdb. Should I install hdf5 from source since I don't have sudo access? I am working on a Linux machine.
I simply installed hdf5 from the source files. While configuring the installation I turned the --enable-build-mode and --enable-symbol switches. Hdf5 has a dependency on szip which I also installed from source code. My exact configuration was as follows:
./configure --prefix=<hdf5 install directory> --enable-cxx --enable-build-mode=debug --enable-symbols=yes --enable-profiling=yes --with-szlib=<szip install directory>
The above solution worked and I was able to compile my h5 application using h5c++ hdf5.cpp and also use gdb to debug it.
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.