I am trying to install cmake on solaris machine by building its source code. In one of the steps we need to do "make" to build the source code. When I do a make I am getting below error
/json_reader.cpp:35:18: error: ‘snprintf’ is not a member of ‘std’
#define snprintf std::snprintf
This indicates that code is using c++11 std but gcc compiler uses c++98 std. I have gcc version 4.8.2 (GCC) in the solaris machine. As per my knowledge make is wrapper over gcc.
Question is: How to set CFLAGS for gcc globally so that when I do a "make" it directly uses c++ 11 std.
Related
I am trying to build cmake source, which requires C++11.
The build halts and apparently the complaint is that C++11 is not detected. The g++ mode is actually set to -std=gnu++17
This is part of the console log
---------------------------------------------
CMake 3.18.20200919, Copyright 2000-2020 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++17
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
g++ -std=gnu++17 -DCMAKE_BOOTSTRAP -DCMake_HAVE_CXX_MAKE_UNIQUE=1 -c $HOME/Apps/CMake-master/Source/cmAddCustomCommandCommand.cxx -o cmAddCustomCommandCommand.o
This is part of the error in the log file...
In file included from /usr/include/c++/5/unordered_map:35:0,
from cmake_bootstrap_11920_test.cxx:4:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support \
^
cmake_bootstrap_11920_test.cxx:7:2: error: #error "Compiler is not in a mode aware of C++11."
#error "Compiler is not in a mode aware of C++11."
^
cmake_bootstrap_11920_test.cxx:70:16: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11
int Member = 1;
Looking around on the web, I noticed that C++11 is only available after gcc version 4.6.
I checked my version, and it seems to be above.
g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609
I understand the -std=c++11 flag is used to enable the C++11 features in g++, but I don't seem to know what I am doing in this case.
I tried editing the CompileFlags.cmake file, but no change occurs.
I came upon this page which points to the cmake source I am using.
It says...
bootstrap: Require compiler mode aware of C++11
Some compilers have enough features enabled in their default modes to
pass our simple C++11 unique_ptr check but do not enable enough to build
CMake. Poison this case so that we choose one of the explicit `-std=`
options for such compilers.
Not sure what that means exactly.
How exactly do I change the g++ mode, to C++11, so that on running the bootstrap command, C++11 is used?
Or, in other words, how do I change std to point to C++11 (-std=c++11)?
First of all, you have g++ version 5.4.0 in your host PC installed, which is good, cause it means this is also supports the C++11, which you want to use.
To set it up, you could define it in your CMakeList.txt file:
set (CMAKE_CXX_STANDARD 11)
that should do the trick.
Please also check the documentation:
https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD.html
Usually, I would suggest to use the latest standard that you compiler is supporting (https://gcc.gnu.org/projects/cxx-status.html), cause you'll get also the latest features introduced in that standard. Exception for this rather in case you are working with legacy codes.
I have gcc 4.8.5 installed on a Red Hat 7.5 machine.
I wish to compile a software package on this machine.
In order to compile this package, I need to run "make".
However, when I run this, I see the following error message "error: ‘make_unique’ is not a member of ‘std’".
My understanding (possibly incorrect) is that this message originates from the fact that 4.8.5 uses C++11 and "make_unique" requires C++14. So I presume the way to compile this is to specify that C++14 should be used when I run "make".
How do I do this ?
I have tried to set the C++ to 14 as follows:
cmake -G "Unix Makefiles" -D CMAKE_CXX_STANDARD=14
And then I ran "make".
But this gave the same error message.
You are using compiler that does not support C++14. As stated in the documentation:
GCC supports the original ISO C++ standard (1998) and contains experimental support for the second ISO C++ standard (2011).
It is no surprise, since GCC 4.8 was originally released in 2013 so it would be weird if it implemented a standard introduced a year later.
To use C++14 or even C++17 you can compile it with RH Devtoolset 8. The built software would run on target OS w/o any additional effort due to the "nature" of DTS compiler: the symbols available in the OS-shipped libstdc++ gonna be resolved dynamically, while C++11 and above gonna be linked to you executable from the specially built static libstdc++.a provided by DTS.
When I'm trying to compile my C/C++ software using gcc/g++ with -m32 option on RedHat 6.10 which is a 64bit OS, we have a Dell isilon file system exporting 64 bit file ID's we get a run-time error using code coverage compile options. I wrote a simple main() test app test.cpp and compile with the following compile options.
g++ --coverage -m32 test.cpp -o test
When I run the 32bit executable we get a run-time error relating to our file system exporting 64bit file ID's vs 32 bit. We don't want to change to a 32bit file ID export.
./test
profiling:test.gcda: Cannot open
If we compile the app without the -m32 option the problem goes away. However, I need to compile with -m32 for other reasons outside the scope of this discussion.
gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)
RedHat 6.10 64bit OS
Thank you for any help.
It appears that a later version of gcc has fixed this problem. I now know that gcc version 8.2.0 compiles properly and doesn't have the error about not being able to find the .gcda file. This makes sense since the Dell isilon system is newer and the gcc compiler version we've been using with RedHat 6.10 is quite old.
I have compiled mpich 3.2 with gcc 4.8.3 on centos. Everything seems to be fine. Then I wrote a simple test program,
#include "mpi.h"
int main(int argc,char **argv)
{}
and use the mpic++ to compile. Then errors return,
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strncmp'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memset'
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to__intel_sse2_strlen'
What exactly goes wrong? I'm so confused that the error seems to be related with intel compilers, but I use gcc to compile mpich by the command,
./configure --prefix=/home/setups/mpich-3.2/build/ CC=gcc CXX=gcc F77=gfortran FC=gfortran
I have added /home/setups/mpich-3.2/build/bin to PATH and /home/setups/mpich-3.2/build/lib to LD_LIBRARY_PATH
mpicc -v shows：
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/setups/gcc-4.8.3/build/libexec/gcc/x86_64-unknown-linux-gnu/4.8.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/setups/gcc-4.8.3/build --with-gmp=/home/setups/gmp-6.1.2/build --with-mpfr=/home/setups/mpfr-3.1.5/build --with-mpc=/home/setups/mpc-1.0.3/build --disable-multilib
Thread model: posix
gcc version 4.8.3 (GCC)
You might find your solution at the open-mpi.org site and their faq for building MPI. For example, item 17.
A common mistake when building Open MPI with the Intel compiler suite
is to accidentally specify the Intel C compiler as the C++ compiler.
Specifically, recent versions of the Intel compiler renamed the C++
compiler "icpc" (it used to be "icc", the same as the C compiler).
Users accustomed to the old name tend to specify "icc" as the C++
compiler, which will then cause a failure late in the Open MPI build
process because a C++ code will be compiled with the C compiler. Bad
Things then happen. The solution is to be sure to specify that the C++
compiler is "icpc", not "icc". For example:
https://www.open-mpi.org/faq/?category=building
/home/setups/mpich-3.2/build/lib/libmpi.so: undefined reference to _intel_fast_memcpy'
This strongly suggests an Intel compiler was used to build mpich.
That can happen is gcc/g++/gfortran is not in your PATH or if your environment points to the Intel compiler (e.g. CC=icc or CXX=icpc or FC=ifort).
I am currently trying to compile libxml2 on Solaris. When I run the ./configure script provided with the sources, the gcc and g++ compilers are automatically used. However, I would like to use cc and CC compilers. So I run :
./configure CC=cc CXX=CC
It works but then, when I run "make", I get some errors which prevent the libraries to be generated.
When gcc and g++ are used, everything goes well with no errors, so I was wondering: can I use the librairies generated with gcc/g++ the same way I would have used them if I had successively generated them with cc/CC?
What are the differences between a lib generated with cc and the same lib generated with gcc on Solaris?
You can use either the gcc or cc C compilers pretty much interchangeably.
You can mix the g++ and CC C++ compilers in certain ways, but only on x86 Solaris and if your CC compiler is new enough to have the -compat=g option available.
The GNU g++ and the Solaris Studio CC C++ compilers default to completely different ABIs and C++ run-time libraries. On x86 Solaris platforms, newer versions (since version 12.?, if I remember correctly) provide a -compat=g option to use the g++ ABI and run-time libraries. The Studio 12.4 CC compiler adds a -std=v option to select different versions of the g++ or Sun C++ ABI and run-time libraries:
c++03 (zero-3, not oh-3)
Equivalent to the -compat=g option. It selects C++ 03 dialect and g++ ABI; it is binary compatible with g++ on Solaris and Linux It
sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
c++11
Selects C++ 11 dialect and g++ binary compatibility. It sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
c++0x (zero-x, not oh-x)
Equivalent to c++11.
and
The -std=c++03 provides compatibility with the gcc/g++ compiler on
all Oracle Solaris and Linux platforms.
With -std=c++03, binary compatibility extends only to shared
(dynamic or .so) libraries, not to individual .o files or archive (.a)
libraries. The gcc headers and libraries used are those provided with
the compiler, rather than the version of gcc installed on the system.
Note that the Studio 12.4 CC compiler uses the g++ headers and libraries supplied bundled with the CC compiler itself. 12.3 and earlier use the g++ headers and libraries installed on the system under /usr/sfw.
On SPARC Solaris, you have to use either g++ or CC for the entire application.