Update
I narrowed down the problem to (probably! it's not entirely clear, even reading all I could find about the topic) that installing stdlibc++-7-dev would provide me with suitable (i.e., C++17-compliant) STL headers and libraries.
This (also, apparently) comes bundled with Ubuntu 17.04 (artful?) but is not available for xenial (Ubuntu 16.04.3 LTS) which is what I'm using.
I have tried downloading the individual .deb packages and installing them, but it quickly becomes a maze of unresolved dependencies.
If anyone could point me to how to install libstdc++-7-dev on 16.04, I'd be most grateful.
Original question
I have just installed clang++ 6.0 in Ubuntu 16.04 via the package manager (following these instructions) and all seems well: /usr/bin/clang++-6.0 works just fine, and if I try to use something that only works in C++17 (non-type template arguments with auto, see here) it compiles and runs, once I set CMAKE_CXX_COMPILER=/usr/bin/clang++-6.0 -- while it fails when I don't.
So... clang 6.0 understands C++17 as advertised (doh!) but when I use:
#include <variant>
the file is not found where I would expect it to be:
$ ll /usr/include/clang/6.0.0/
total 0
lrwxrwxrwx 1 root root 45 Aug 6 21:32 include -> ../../../lib/llvm-6.0/lib/clang/6.0.0/include
or anywhere else I can think of.
Would anyone know (a) whether it's supposed to be there at all and (b) if so, where do I go find it?
Update
I have double-checked that I have the latest (I think) stdc++ library:
$ sudo apt-get install libstdc++-5-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libstdc++-5-dev is already the newest version (5.4.0-6ubuntu1~16.04.4).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
and same for libstdc++-6-dev; also, I have libc++-dev:
$ sudo apt-get install libc++-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc++-dev is already the newest version (3.7.0-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Still, the variant.h* file is nowhere to be found.
Anything else I should try?
Yes, clang 5.0 (or rather, the libc++ that will ship as part of clang 5) has the <variant> header. But you need to be sure that you have installed libc++.
And as #KayEss mentioned, you'll need to pass -std=c++17 (or the earlier version of the same flag -std=c++1z) because variant is a C++17-only feature.
Related
I'm having trouble installing the "car" package after upgrading R to 3.6.2 (from 3.4) on Ubuntu 16.04 due to (at least one) dependency (nloptr) that cannot be installed either. It seems to be a problem of the C++ compiler (it is using some deprecated "config" settings, however I'm lost trying to fix this).
I called the following command in R (from the terminal):
install.packages("nloptr")
Error Information:
Installing package into ‘/home/heike/R/x86_64-pc-linux-gnu-library/3.6’
(as ‘lib’ is unspecified)
--- Please select a CRAN mirror for use in this session ---
trying URL 'https://ftp.fau.de/cran/src/contrib/nloptr_1.2.1.tar.gz'
Content type 'application/x-gzip' length 2448313 bytes (2.3 MB)
==================================================
downloaded 2.3 MB
* installing source package ‘nloptr’ ...
** package ‘nloptr’ successfully unpacked and MD5 sums checked
** using staged installation
'config' variable 'CPP' is deprecated
'config' variable 'CXXCPP' is deprecated
checking whether the C++ compiler works... no
configure: error: in /tmp/RtmpPLaJFA/R.INSTALL5e5ed06eeac/nloptr': configure: error: C++ compiler cannot create executables See config.log' for more details
ERROR: configuration failed for package ‘nloptr’
Steps taken so far
changed CRAN mirror and source.list entry
uninstalled and reinstalled R 3.6.2 (also on different machine), same issue remained
System Information
OS Version: Ubuntu 16.04 (x86_64-pc-linux-gnu (64-bit))
R Version: 3.6.2 (2019-12-12)
We have done a lot of work to make nloptr installation better. In essence, you have several choices:
if the system version of the nlopt library is present, use it -- that is the easiest so try installing it via sudo apt-get install libnlopt-dev and then reinstall
if it is not found, then a download of the source and build happens, and this seems to fail on your almost four year old Ubuntu system as it is hard to support all flavours --- but this works swimmingly on newer ones (I run Ubuntu too, but currently 19.10)
there are binaries for you as, see the Ubuntu packages page -- however these may not match your current R version which is mismatches to your distro R version
dependening on where you got R from (did you install a .deb?) you could use the Michael Rutter PPAs to get a current r-cran-nloptr
All this can also be discussed in detail on the r-sig-debian list for R on Debian and Ubuntu.
Edit: In response to the comment below:
To see what package apt knows about, do apt-cache policy r-cran-nloptr. Per the link I gave above we know Ubuntu has a r-cran-nloptr for your (very old) Xenial installation. However it will clash with the very new and current R you have running. Such as the costs of mixing and matching.
To access the Rutter PPAs and its over four thousand current binaries see the fourth paragraph at the top of the Ubuntu at CRAN README
Edit 2: I may have been too pessimistic. The Rutter PPA for the current R binaries has trusty, xenial and bionic. See https://launchpad.net/~marutter/+archive/ubuntu/c2d4u3.5
I am running centos 6 on a cluster. I installed the latest gcc-8.2.0. and made a link "ln -sf /usr/bin/gcc-8.2 gcc".
I did the same for g++ and gfortran.
I wanted to reinstall gcc-8.2.0 and went ahead to
make clean
in the gcc-8.2 directory.
When I try
./configure
I get that C compiler cannot create executables
The links I made are broken.
The system gcc-4.4.7 cannot be found
which gcc
gives no gcc
sudo yum install gcc gcc-c++
gives gcc is already installed.
I tried to install an rpm, which fails because of dependencies.
I have pg compilers installed in /opt/pgi
When I configure with
CC=/path to/pgi/bin/pgcc FC=/path to/pgi/bin/pgfortran ./configure
I still get C compiler cannot create executables
I tried the following c++ programm
#include <iostream>
using namespace std;
int main() {
cout << "Hello world!" << endl;
return 0;
}
With the command
/opt/pgi/linux_86_64/12.08/bin/pgcpp hello.cpp -o hello
It gives compilation error that float.h not found. On another linux PC with working gcc, the program works with the command
g++ hello.cpp -o hello
I will appreciate any assistance to either find the systemgcc or use pg compilers to compile gcc if possible
I admit it is a big mess which will require OS reinstallation and reconfiguration. But then I did
sudo yum install compat-gcc-34
Now I have gcc34 and configure of gcc-8.2 goes through without "c compiler cannot create executables". (Note that the ./configure referred to in earlier post was actually
../gcc_8_2_release/configure
inside "gcc_8_2_release_build, so gcc was not being built in its source directory.
The problem I have now is with make, which needs g++, giving error
uint_t(64) or int_t(64) not found.
Thanks all who have gone through this post, for your patience.
Any assistance will be appreciated.
Here is how I got out of this mess.
With the following two commands
sudo yum install compat-gcc-34-c++
sudo yum install compat-gcc-34-g77
I was able to install the older version of gcc, c++ and g77. Then I was able to build gcc-8.2.
Now I have a functional system with the latest gcc, yes it may need re-installation/re-configuring but it is fully functional.
I have learnt a lot and very much appreciate the comments and guidelines of #Basile. However, at one point he was rather negative and discouraging.
But thanks to my belief and perseverance, and more importantly browsing the knowledge shared by others, I have been able to recover what I was beginning to be convinced was a lost cause.
Thanks all.
This is more a sysadmin question than a programming one.
My recommendations:
don't mess your /usr/bin/. Leave your package manager yum to fill it -and never add anything inside it without yum ; so remove manually any symlinks you made there (by mistake)
reinstall the old system gcc 4.4 and g++ 4.4 (using yum)
rebuild your GCC 8 from scratch from its source code. Configure it with --program-suffix=-8 (but no --prefix, or a --prefix=$HOME/soft/ if you don't have root access). So it will install /usr/local/bin/gcc-8 and /usr/local/bin/g++-8 etc... (or, if you have given --prefix=$HOME/soft/ , a $HOME/soft/bin/gcc-8 etc...)
create a $HOME/bin/ if you don't have already one
be sure to have $HOME/bin/ early in your $PATH (before /usr/bin/)
add a symlink ln -sv /usr/local/bin/gcc-8 $HOME/bin/gcc and likewise for g++ etc..
Then, when you type gcc you are getting that symlink to /usr/local/bin/gcc-8 etc.
If you cannot write to /usr/local/ (e.g. because you don't have root permission...) you could pass --prefix=$HOME/soft/ to GCC 8 .../configure then replace /usr/local/ above with $HOME/soft/
If you are the sysadmin and can write to /usr/local/ and have to set up things for many users: add a symlink ln -s /usr/local/bin/gcc-8 /usr/local/bin/gcc etc and ask your users to put /usr/local/bin/ in their $PATH before /usr/bin/
BTW, notice that it is explicitly documented that GCC 8 (or others) need to be built outside of its source tree: in Installing GCC you can read:
First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree.
(the "highly recommend" should be considered as a polite way to say "you absolutely should")
So your ./configure was another mistake.
It could happen that you messed up your system more seriously than you thought (and perhaps you need to reinstall, or to call Redhat support).
PS. I don't know Redhat (used it only in the previous century). My favorite distro is Debian/testing or Debian/unstable (and my computers are desktops, not clusters).
This problem was solved by the following commands
sudo yum install compat-gcc-34-c++
sudo yum install compat-gcc-34-g77
Once this older version of gcc is installed, the latest version, gcc-8.2 was built and the system is no longer messed terribly. It is very healthy and fit.
I have code that depends on <X11/Xlocale.h>. When I try to compile with the emscripten tool chain (after CMake generate), I get the following error. What do I need to change in my configuration?
'X11/Xlocale.h' file not found
# include <X11/Xlocale.h>
^~~~~~~~~~~~~~~
1 error generated.
I'm doing this on Linux.
$ uname -a
Linux bracket 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
I've confirmed I have libx-dev installed.
$ sudo apt-get install libx11-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
libx11-dev is already the newest version (2:1.6.4-3).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Emscripten can't use native libraries -- it's outputting Javascript code, after all; it can't use libraries which contain native x86 (or other architecture) code. As such, emscripten won't search for headers in your system's include directories, because a lot of those headers will describe functionality which isn't available to an Emscripten program. It uses internal search paths instead.
Now, <X11/Xlocale.h> is a bit of a weird header. It doesn't actually define anything; it just includes <locale.h>, so you may be able to get away with replacing #include <X11/Xlocale.h> with #include <locale.h>. However, if your application uses other X11 functionality, it may not be buildable under Emscripten.
OS: Ubuntu 14.04
g++: g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
R version: 3.2.0 (2015-04-16) -- "Full of Ingredients"
Rcpp: 0.11.6
Today I apt-get dist-upgrade my system, and the g++ was also been upgraded.
Then when I am trying to use "Rcpp" package in R, the code is the simplest test code >>evalCpp("1+1") . An error as follows occurred:
Error in frameTypes(env) : not a proper evaluation environment
Calls: ::: ... tryCatch -> tryCatchList -> tryCatchOne -> <Anonymous>
Execution halted
Error in sourceCpp(code = code, env = env, rebuild = rebuild,showOutput = showOutput, :
Error 1 occurred building shared library.
WARNING: The tools required to build C++ code for R were not found.
Please install GNU development tools including a C++ compiler.
I have did google for it. The following links are all about Mac OSX:
Error when with Xcode 5.0 and Rcpp (Command Line Tools ARE installed)
g++ errors when trying to compile c++11 with Rcpp
From the answers and comments, I can not tell what is the real problem.
Appreciate your help!
UPDATE: I finally solved this problem by reinstalling all the R related deb packages. And one thing we should keep in mind is that I also did what #Dirk suggested first apt-get build-dep r-base-dev. I can not confirm which one is the key step.
You need
sudo apt-get build-dep r-base
to install the all the build dependencies for R itself.
But we even built an explicitly helper package r-base-dev so in most cases (and in your use case of Rcpp) you just need
sudo apt-get install r-base-dev
There is something wrong/missing in your system configuration. First of all, I doubt that you are really running Ubuntu 14.04 (after the dist-upgrade) because the the other versions that you listed wouldn't be available (unless you have pulled them in from a non-default repository). You might also consider running a full-upgrade to try to straighten out your configuration.
You might gain some insights by running with showOutput=1...
library(Rcpp)
evalCpp("1+1",showOutput=1,rebuild=1)
...but actually, it looks like the problem is related specifically to a parameter called env (Error in frameTypes(env) : not a proper evaluation environment) which is likely evaluated prior-to attempting to compile.
For what it is worth, I was able to run this without r-base-dev installed, but maybe installing r-base-dev will pull in the correct, and updated, versions of what you need. I would be inclined to just reinstall all R-related packages.
I am trying to install (offline installer) Qt 5.4.0 on linux 14.04 "Trusty Tahr" and I keep getting the error message:
Warning: /home/bd-01/Qt5.4.0//Tools/QtCreator/bin/sdktool: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory
I've googled and searched and the answer seems to be to install libgl-dev and libglu-dev but they are already installed, per the console messages I see when installing each:
libgl-dev
`Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libgl1-mesa-dev' instead of 'libgl-dev'
libgl1-mesa-dev is already the newest version.
libgl1-mesa-dev set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 598 not upgraded.`
libglu-dev
`Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libglu1-mesa-dev' instead of 'libglu1-mesa-dev'
libglu1-mesa-dev is already the newest version.
libglu1-mesa-dev set to manually installed.
0 upgraded, 0 newly installed, 0 to remove and 598 not upgraded.`
So I see 2 possible problems but don't know how to adress either.
'libglu1-mesa-dev' is being substituted for 'libglu1-mesa-dev'
libglu1-mesa-dev set to manually installed
Can anyone help me understand what is going on here?
Given that you have the following items done proper:
sudo apt-get install libgl1-mesa-dev
not mixing 32 and 64 bits
you used the proper download URL
/usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 is available
etc
... it seems that, as I suspected, your system was b0rked. When you are dealing with packages through the package manager, you need to ensure that the system is in a clean and proper, and not in a broken state.
Things, like apt-get auto remove run means that you system is fundamentally broken and you have to fix your system first before experimenting with packages on top of it.