When I trying to compile ArangoDB 3.0, I am getting this issue as below.
wget https://www.arangodb.com/repositories/Source/ArangoDB-3.0.0.tar.gz
tar -xvvf ArangoDB-3.0.0.tar.gz
ln -s ArangoDB-3.0.0 arangodb
OR
git clone https://github.com/arangodb/arangodb
cd arangodb
git checkout 3.0
git pull
I have tried both above binary for compile as below.
cd arangodb/
mkdir -p build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
Executing cmake .. -DCMAKE_BUILD_TYPE=Release command give me following error.
-- Checking C++11 support for "regex"
CMake Error at cmake/CheckCXX11Features.cmake:129 (message):
Checking C++11 support for "regex": not supported
Call Stack (most recent call first):
cmake/CheckCXX11Features.cmake:150 (cxx11_check_feature)
CMakeLists.txt:265 (include)
-- Configuring incomplete, errors occurred!
See also "/home/ec2-user/arangodb/build/CMakeFiles/CMakeOutput.log".
OS version on AWS Linux AMI:
Linux 4.4.11-23.53.amzn1.x86_64 #1 SMP Wed Jun 1 22:22:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
GCC version:
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Regex support was added in gcc 4.9
- #Bill-Lynch
You have two options:
Install a newer compiler.
Go through the code and replace all regexes with equivalent functions.
Related
I was trying to activate the option -Wmismatched-tags on gcc (detect inconsistent class/struct declaration, which might happens when using forward declaration), but on Ubuntu I get
c++: error: unrecognized command line option '-Wmismatched-tags'
My gcc version:
# gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
Looking here it seems like it was integrated in gcc 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
Am I doing something wrong, or is the option actually not available anymore?
I am aware of Can GCC produce struct/class name mismatches like VS?, however the answer is 10 years old and I was hoping things had improved in the meantime.
Background: I need this in a project where we also build with clang, and where these inconsistencies are treated as error.
Looking here it seems like it was integrated in gcc 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61339
Actually, it doesn't. It was reported in 2014 but as OP explained in
#5th post:
I can't speak for MS, but the original warning I posted was produced
by clang. It does seem to worry about mismatched tags.
In gcc -Wmismatched-tags was introduced only in December 2019 and
became a part of GCC 10 release:
$ git describe e8f1ade269a39ea86a76a2440818e1512ed480ee
basepoints/gcc-10-5517-ge8f1ade269a
Luckily, these days we have docker and official GCC releases are
officially distributed as docker images:
$ docker search gcc
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
gcc The GNU Compiler Collection is a compiling s… 587 [OK]
(...)
so you can just do:
docker run --rm -it gcc
and either mount your source directory into the docker container or
use TRAMP integration for docker
containers or any other
preferred tool to put your code into the container and use the newest gcc inside it:
root#53d309d5d619:/# g++ --version
g++ (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
root#53d309d5d619:/# g++ hello.cpp -o hello -Wmismatched-tags
I am working on RHEL 7.5 and trying to compile a uWebSocket (This exaple) code. I clone the project and open it. When I start make on Makefile I got this error;
BroadcastingEchoServer uSockets/*.o -lz;
g++: error: unrecognized command line option '-std=c++17'
make: [examples] Error 1>
The main problem is -std=c++17 is not recognized. How can I control what c++ version I have (that 17 in the end) and how can I install required version.
gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Thanks
RHEL is providing newer versions of GCC additionally using socalled Software Collections (SCL). In your case you could enable this repository (depending whether you have a workstation or a server subscription):
subscription-manager repos --enable rhel-server-rhscl-7-rpms
subscription-manager repos --enable rhel-workstation-rhscl-7-rpms
Afterwards you could install one (or multiple) of the following packages:
yum install devtoolset-6-gcc-c++ (GCC 6.3.1, until RHEL 7.7)
yum install devtoolset-7-gcc-c++ (GCC 7.3.1)
yum install devtoolset-8-gcc-c++ (GCC 8.3.1)
yum install devtoolset-9-gcc-c++ (GCC 9.3.1, since RHEL 7.7)
yum install devtoolset-10-gcc-c++ (GCC 10.2.1, since RHEL 7.9)
yum install devtoolset-11-gcc-c++ (GCC 11.2.1, since RHEL 7.9)
Note that you can install the whole devtoolset of a specific version using e.g. yum install devtoolset-11-toolchain. This might be needed (or not) depending on your specific usecase.
Once installed, run e.g. scl enable devtoolset-11 bash when you installed devtoolset-11-gcc-c++. Calling g++ will then lead to GCC 11.2.1. For scripts, using . /opt/rh/devtoolset-11/enable before using g++ might be more convenient.
If needed, see How can I make a Red Hat Software Collection persist after a reboot/logout? in the Red Hat Knowledgebase.
gcc (GCC) 4.8.5
C++17 is not supported by GCC v4.8.
C++17 is not supported by GCC v4.9.
C++17 is supported by GCC v5, but you need -std=c++1z:
The next revision of the ISO C++ standard, tentatively planned for 2017. Support is highly experimental, and will almost certainly change in incompatible ways in future releases.
GCC v5 was released 2015 and they did not yet have time machines back then ;o)
Same applies to GCC v6 and GCC v7 (released 2016 and 2017).
C++17 is supported by GCC v8 by means of -std=c++17 (and by -std=c++1z which is deprecated since then).
For the GNU-C++ dialects, use -std=gnu++* instead of -std=c++*.
Hence for serious projects, you should use GCC v8 or newer.
Use:
yum install devtoolset-9-toolchain
scl enable devtoolset-9 bash
I have run in an issue with compiling gdb from source. I am downloading version 8.2.1 but when I try to compile it, I get the following error:
configure: error: *** A compiler with support for C++11 language features is required.
make[1]: *** [configure-gdb] Error 1
My operating system is Red Hat 7.6 (Maipo) but i have a compiled from source gcc(that i set as the default one with an alias in bashrc)
gcc --version
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
which gcc
alias gcc='/usr/local/gcc8.2/bin/gcc'
/usr/local/gcc8.2/bin/gcc
which g++
alias g++='/usr/local/gcc8.2/bin/g++'
/usr/local/gcc8.2/bin/g++
What i have tried/read so far
Read the gdb manual regarding the configure and instalation part, also various stackoverflow links but nobody seems to have this problem
Read the README file in the gdb folder/subfolders
Tried setting the following env options CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++ GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc (not sure if i should replace target with my actual target architecture)
Looked in the gdb-8.2.1 folder at the file config.log and found these: ac_cv_env_GCC_FOR_TARGET_value=/usr/local/gcc8.2/bin/gcc
ac_cv_prog_CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++
ac_cv_prog_GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc
However in the C compiler section of the same config log I have found the following:
configure:4284: checking for C compiler version
configure:4293: gcc --version >&5
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I am not sure ifi can use the devtoolset-8 gdb from RedHat because i have compiled gcc with GLIBCXX_USE_CXX11_ABI=1 and on RedHat due to a bug this is disabled by default and i am not sure if gdb will be able to manage the different binary interface.
Short version: What am I doing wrong that is making the GDB configure script not find the correct compiler and how can i fix/workaround this?
Thank you very much for your help!
A C++11-capable compiler for Red Hat Enterprise Linux 7 is provided as part of Red Hat Developer Toolset. It happens to include not just GCC 8, but GDB 8.2 as well, so you may not even have to compile it yourself. The DTS C++ compiler has been built in a special way so that it interoperates with the system C++ runtime. Unless you have replicated those modifications in your GCC build, it will not be compatible with the rest of the system (and you will have to replace the system libstdc++ library).
The system compiler in Red Hat Enterprise Linux 7 is based on GCC 4.8. In that version, C++11 support was still experimental and not enabled by default. You can try to configure GDB with
./configure CXX="g++ -std=gnu+11"
but this is not recommended (only the C++98 mode is supported).
The configure script does not use shell aliases because those are not inherited by shell scripts invoked from a shell. You will have to specify the full path to the C++ compiler explicitly (in the CXX= argument to configure), or adjust the PATH environment variable manually, or use scl enable to do so in a more polished fashion (for software collections such as Developer Toolset).
I am trying to bootstrap cmake 3.11.3 on Ubuntu 16.04.4 LTS xenial.
I have upgrade my gnu g++ compiler as follows:
> $ g++ --version
g++ (Ubuntu 8.1.0-5ubuntu1~16.04) 8.1.0 Copyright (C) 2018 Free
Software Foundation, Inc. This is free software; see the source for
copying conditions. There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.
And manually re-pointed the symbolic links:
$ ll /usr/bin/*g++*
lrwxrwxrwx 1 root root 5 Jun 8 16:57 /usr/bin/g++ -> g++-8*
-rwxr-xr-x 1 root root 919832 Apr 24 15:02 /usr/bin/g++-5*
lrwxrwxrwx 1 root root 22 Jun 6 04:26 /usr/bin/g++-8 -> x86_64-linux-gnu-g++-8*
lrwxrwxrwx 1 root root 22 Jun 8 16:58 /usr/bin/x86_64-linux-gnu-g++ -> x86_64-linux-gnu-g++-8*
lrwxrwxrwx 1 root root 5 Apr 24 15:02 /usr/bin/x86_64-linux-gnu-g++-5 -> g++-5*
-rwxr-xr-x 1 root root 1071984 Jun 6 04:26 /usr/bin/x86_64-linux-gnu-g++-8*
However, I get the following error in the configuration of cmake:
$ sudo ./bootstrap
---------------------------------------------
CMake 3.11.3, Copyright 2000-2018 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
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>
---------------------------------------------
make: Warning: File 'Makefile' has modification time 2.3 s in the future
make: 'cmake' is up to date.
make: warning: Clock skew detected. Your build may be incomplete.
loading initial cache file /mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/Bootstrap.cmk/InitialCacheFlags.cmake
CMake Error at CMakeLists.txt:92 (message):
The C++ compiler does not support C++11 (e.g. std::unique_ptr).
-- Configuring incomplete, errors occurred!
See also "/mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/CMakeFiles/CMakeOutput.log".
See also "/mnt/ganymede/user/gpeytavi/srv_admin/software/cmake-3.11.3/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------
Any idea why I get a c++11 std::unique_ptr non-compliant error?
In my case, the issue is because of the folder where I have CMake source code is in a mounted directory (in fact my entire rootfs is mounted over NFS)
So, I looked in 'mount' command output and selected '/run/user/1000' location as a local location as this is mounted using tmpfs and moved my CMake source code to this location.
with this, ./bootstrap && make && sudo make install executed successfully.
Actually the ./bootstrap script does try the different C++ standard flags with the compiler. So it should detect its capabilities automatically.
Please make sure you don't have any CXXFLAGS environment variable set and try from scratch again (the messages/warnings you get indicate several tries/errors in the same directory).
Output when Successful
As a reference on my Ubuntu calling CMake's ./bootstrap looks like this:
---------------------------------------------
CMake 3.11.20180423, Copyright 2000-2018 Kitware, Inc. and Contributors
Warning: This is an in-source build
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++ -std=gnu++1y
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>
---------------------------------------------
Debugging
For debugging your problem you also could:
Call ./bootstrap --verbose
Look into Bootstrap.cmk/cmake_bootstrap.log
Known Problem
I only once had a problem with bootstrap using clang compilers where I needed to do the following call:
export CXXFLAGS=-Xclang -std=c++1z -Xclang -stdlib=libc++
Alternative
If you just want to install the latest version see How to specify where CMake is installed in Ubuntu?
I was able to resolve the issue by ensuring that both the build machine and the NFS file server were synchronized by running ntpd on both.
For me it was clock skew. I use the below command :
date -s "2021-11-30 15:08:21"
to set the time to now for the server. Then it work, thanks...
this page (from Arnim Läuger in 2005) explains that a tool chain {GHDL + gcov} can perform VHDL code coverage.
Question : Is it still working today with recent versions of GCC, GCOV and GHDL?
The following command fails
$ ghdl -a -Wc,-ftest-coverage -Wc,-fprofile-arcs tb_example.vhd
ghdl: unknown option '-Wc,-ftest-coverage' for command '-a'
My setup is as follow:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/gnat/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.4/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --enable-languages=ada,c,c++ --enable-dual-exceptions --enable-_cxa_atexit --enable-threads=posix --with-bugurl=URL:mailto:report#adacore.com --disable-nls --without-libiconv-prefix --disable-libstdcxx-pch --disable-libada --enable-checking=release --disable-multilib --with-mpfr=/boron.a/gnatmail/sandbox/gpl-2016/x86_64-linux/mpfr_stable/install --with-gmp=/boron.a/gnatmail/sandbox/gpl-2016/x86_64-linux/gmp_stable/install --with-mpc=/boron.a/gnatmail/sandbox/gpl-2016/x86_64-linux/mpc_stable/install --with-build-time-tools=/boron.a/gnatmail/sandbox/gpl-2016/x86_64-linux/gcc/build/buildtools/bin --prefix=/boron.a/gnatmail/sandbox/gpl-2016/x86_64-linux/gcc/pkg --build=x86_64-pc-linux-gnu
Thread model: posix
gcc version 4.9.4 20160426 (for GNAT GPL 2016 20160515) (GCC)
$ gcov -v
gcov (GCC) 4.9.4 20160426 (for GNAT GPL 2016 20160515)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
$ ghdl -v
GHDL 0.34dev (20151126) [Dunoon edition]
Compiled with GNAT Version: GPL 2016 (20160515-49)
mcode code generator
Written by Tristan Gingold.
Copyright (C) 2003 - 2015 Tristan Gingold.
GHDL is free software, covered by the GNU General Public License. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat /proc/version
Linux version 4.4.0-34-generic (buildd#lgw01-20) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016
I installed GHDL using the Building with mcode backend procedure. Could it be the root of the evil?
Thanks for help!
Yes, current ghdl does support code coverage.
Make sure you have a recent ghdl version, but note that while ghdl suppports 3 code generation backends (LLVM, gcc and its own JIT compiler, mcode), only the gcc backend currently supports code coverage (via gcov). Specifically, the mcode version you have built will not work.
There ought to be suitable packages for Ubuntu - failing that I have build instructions somewhere for building from source on Debian Jessie which ought to serve for Ubuntu too. (I'll dig them out if need be).
ghdl --version
GHDL 0.34dev (20151126) [Dunoon edition]
Compiled with GNAT Version: 4.9.3
GCC back-end code generator
Written by Tristan Gingold.
check...
Now there are some compile time flags you need to supply...
ghdl -a --std=08 -g -fprofile-arcs -ftest-coverage myfile.vhd
ghdl -a --std=08 -g -fprofile-arcs -ftest-coverage my_TB.vhd
and for elaboration (-Wl, precedes linker options)...
ghdl -e --std=08 -Wl,-lgcov -Wl,--coverage my_tb
./my_tb
and you should have a set of .gcno,.gcda files to be post-processed with gcov (or lcov and genhtml, for prettier reports)
Also works under Vunit and with the OSVVM library.
Branch coverage does not work so well, in part because VHDL's signal assignment semantics translate into a lot of spurious branches in the generated executable.
Under VUnit, I don't use their "code coverage" experimental option.
Instead, I set the relevant flags, run the vu.main() function, catch its return, and invoke lcov as a postprocessing step. An incomplete example run.py script is as follows:
lib.add_compile_option("ghdl.flags", ["-fprofile-arcs"])
vu.set_sim_option("ghdl.flags", ["-Wl,-lgcov"])
try:
vu.main()
except SystemExit as exc:
all_ok = exc.code == 0
if all_ok:
subprocess.call(["lcov", "--capture", "--directory", ".", "--output-file", "code_coverage.info"])
subprocess.call(["genhtml", "code_coverage.info", "--output-directory", "code_html"])