My Cygwin suddenly started to give problems running CDO commands:
cdo -sinfo file.nc
cdo sinfo: Open failed on >file.nc<
Unknown Error
I was operating on this file until few weeks ago. Both Cygwin and CDO should be up to date, so I'm failing to understand what's wrong:
$ cdo -V
Climate Data Operators version 1.9.8 (https://mpimet.mpg.de/cdo)
System: x86_64-unknown-cygwin
CXX Compiler: g++ -g -Wall -O2 -DPIC -pie -mwindows -ftree-vectorize -fopenmp
CXX version : g++ (GCC) 7.4.0
C Compiler: gcc -g -Wall -O2 -DPIC -pie -mwindows -ftree-vectorize -fopenmp
C version : gcc (GCC) 7.4.0
F77 Compiler: gfortran -g -O2
F77 version : GNU Fortran (GCC) 7.4.0
Features: 15GB 8threads C++14 Fortran DATA PTHREADS OpenMP HDF5 NC4/HDF5 OPeNDAP UDUNITS2 PROJ SSE2
Libraries: HDF5/1.10.2 proj/5.2.0
Filetypes: srv ext ieg grb1 grb2 nc1 nc2 nc4 nc4c nc5
CDI library version : 1.9.8
cgribex library version : 1.9.4
ecCodes library version : 2.9.0
NetCDF library version : 4.6.1 of May 26 2018 18:07:01 $
hdf5 library version : 1.10.2
exse library version : 1.4.1
FILE library version : 1.8.3
and Cygwin:
$ uname -r
3.1.7(0.340/5/3)
Am I missing something?
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!
Consider the situation when a C++ project is built and shipped within a Centos 7 virtual machine or container. Default gcc for Centos 7 is 4.8. In order to allow developers to use modern C++, the more recent version of gcc (for example, 6.3) is installed into Centos 7 which runs as a CI server. This provides -std=c++14 support.
[builder#f7279ae9f33f build (master %)]$ /usr/bin/c++ -v 2>&1 | grep version
gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
[builder#f7279ae9f33f build (master %)]$ /opt/rh/devtoolset-6/root/usr/bin/c++ -v 2>&1 | grep version
gcc version 6.3.1 20170216 (Red Hat 6.3.1-3) (GCC)
export CXX=/opt/rh/devtoolset-6/root/usr/bin/c++
make all -j4
...
This is short example of compilation and linkage command:
[ 78%] Building CXX object CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o
/opt/rh/devtoolset-6/root/usr/bin/c++ -Ducsdos_EXPORTS -I/home/builder/src/dos/libucsdos/./src -I/home/builder/src/dos/libucsdos/./include -I/home/builder/src/dos/libucsdos/build/schema/cpp -I/home/builder/src/dos/libucsdos/build/schema -isystem /usr/local/include -O2 -g -DNDEBUG -fPIC -frtti -pedantic -Wall -Wextra -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Wformat=2 -Winit-self -Wlogical-op -Wmissing-declarations -Wmissing-include-dirs -Wnoexcept -Wold-style-cast -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-conversion -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=5 -Wswitch-default -Wundef -Werror -Wno-unused -std=gnu++14 -o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -c /home/builder/src/dos/libucsdos/src/merge_operator_string.cpp
[ 80%] Linking CXX shared library libucsdos.so
/usr/bin/cmake3 -E cmake_link_script CMakeFiles/ucsdos.dir/link.txt --verbose=1
/opt/rh/devtoolset-6/root/usr/bin/c++ -fPIC -O2 -g -DNDEBUG -shared -Wl,-soname,libucsdos.so.0 -o libucsdos.so.0.3.23 CMakeFiles/ucsdos.dir/src/c.cpp.o CMakeFiles/ucsdos.dir/src/crdt_2p_set.cpp.o CMakeFiles/ucsdos.dir/src/crdt_pn_counter.cpp.o CMakeFiles/ucsdos.dir/src/errors.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_document.cpp.o CMakeFiles/ucsdos.dir/src/merge_index_segment.cpp.o CMakeFiles/ucsdos.dir/src/merge_operator_string.cpp.o -Wl,-rpath,/usr/local/lib: schema/libschema.a /usr/lib64/librocksdb.so /usr/lib64/libjemalloc.so /usr/local/lib/libgrpc++_reflection.so /usr/local/lib/libgrpc++.so /usr/local/lib/libgrpc.so -ldl -lgrpc++ /usr/lib64/libprotobuf.so -lpthread /usr/lib64/libprotobuf-lite.so
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
[builder#f7279ae9f33f build (master %)]$ ldd libucsdos.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2a4a054000)
It's easy to find out that /lib64/libstdc++.so.6 version is 4.8.5:
[builder#f7279ae9f33f build (master %)]$ yum whatprovides "/lib64/libstdc++.so.6"
libstdc++-4.8.5-28.el7_5.1.x86_64 : GNU Standard C++ Library
Repo : #Updates
Matched from:
Filename : /lib64/libstdc++.so.6
Is this build environment configuration valid?
Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
I can build c++ projects without c++ modules with build2, but when i try to configure and use build2 with c++ modules, I have "compiler does not support modules" error.
I'm sure my compiler is capable of building modules, because I can manually build using these commands:
clang++ --std=c++17 -fmodules-ts --precompile foo.cppm -o foo.pcm
clang++ --std=c++17 -fmodules-ts --precompile foo2.cppm -o foo2.pcm
clang++ --std=c++17 -fmodules-ts -c foo.pcm -o foo.o
clang++ --std=c++17 -fmodules-ts -c foo2.pcm -o foo2.o
clang++ --std=c++17 -fmodules-ts -fprebuilt-module-path=. foo.o foo2.o bar.cpp
Version of my clang is 7.0.0:
$ clang++ --version
clang version 7.0.0- (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
To enable modules support in build2 I added following lines to root buildfile:
cxx.std = experimental
using cxx
assert $cxx.features.modules 'compiler does not support modules'
mxx{*}: extension = mxx
cxx{*}: extension = cxx
What can be wrong? It's my first time with build2, so I can be missing something very simple.
Managed it to work.
As I understand the problem was that I changed buildfile, but should use build/root.build instead.
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.
I'm trying to configure eclipise kepler to use c++ 11.
I appended -std=c++11 to:
Properties > c/c++ build > settings > GCC c++ complier > Miscellaneous>other flags
But when I compile the project it says:
compilation terminated. /bin/sh: 1: -std=c++11: not found
I'm using gcc on ubuntu,
any ideas?
Flags (or compiler options) are nothing but ordinary command line arguments passed to the compiler executable.
Assuming you are invoking g++ from the command line (terminal):
$ g++ -Wall -g -std=c++11 your_file.cpp -o your_program
or
$ g++ -Wall -g -std=c++0x your_file.cpp -o your_program
if the above doesn't work.
So in your case if -std=c++11 does not work, try -std=c++0x
Another source for this error could be an old compiler version.
Type gcc --version into the terminal and check the version. Here is a quick overview which version is capable of c++11:
C++11 Support in GCC
GCC 4.8.1 was the first feature-complete implementation of the 2011
C++ standard, previously known as C++0x.
This mode can be selected with the -std=c++11 command-line flag, or
-std=gnu++11 to enable GNU extensions as well.
Link: https://gcc.gnu.org/projects/cxx-status.html