Compilation fails for ‘RcppParallel’ on Ubuntu 20.04; "error: ‘copy_exception’ is not a member of ‘std"
Closed this issue · 14 comments
I'm stuck. Installing RcppParallel in R 4.0.3 under Ubuntu 20.04 gives an error:
"error: ‘copy_exception’ is not a member of ‘std’".
Can't find a solution googling around.
Here's the full output and sessionInfo:
install.packages("RcppParallel")
Installing package into ‘/home/apollo/R/x86_64-pc-linux-gnu-library/4.0’
(as ‘lib’ is unspecified)
trying URL 'https://cloud.r-project.org/src/contrib/RcppParallel_5.0.2.tar.gz'
Content type 'application/x-gzip' length 1341240 bytes (1.3 MB)
==================================================
downloaded 1.3 MB
- installing source package ‘RcppParallel’ ...
** package ‘RcppParallel’ successfully unpacked and MD5 sums checked
** using staged installation
** preparing to configure package 'RcppParallel' ...
*** configured file: 'src/Makevars.in' => 'src/Makevars'
** finished configure for package 'RcppParallel'
** libs
Created ../build/lib_release directory
../../build/Makefile.tbb:32: CONFIG: cfg=release arch=intel64 compiler=clang target=linux runtime=cc9_libc2.31_kernel5.4.0
In file included from ../../include/tbb/concurrent_hash_map.h:34,
from ../../src/tbb/concurrent_hash_map.cpp:21:
../../include/tbb/tbb_exception.h: In constructor ‘tbb::internal::tbb_exception_ptr::tbb_exception_ptr(const tbb::captured_exception&)’:
../../include/tbb/tbb_exception.h:348:25: error: ‘copy_exception’ is not a member of ‘std’; did you mean ‘bad_exception’?
348 | my_ptr(std::copy_exception(src)) // early C++0x drafts name
| ^~~~~~~~~~~~~~
| bad_exception
make[2]: *** [../../build/common_rules.inc:79: concurrent_hash_map.o] Error 1
make[1]: *** [Makefile:104: tbb_release] Error 2
cp: cannot stat 'tbb/build/lib_release/libtbb*.*': No such file or directory
make: *** [Makevars:89: tbb] Error 1
ERROR: compilation failed for package ‘RcppParallel’ - removing ‘/home/apollo/R/x86_64-pc-linux-gnu-library/4.0/RcppParallel’
Warning in install.packages :
installation of package ‘RcppParallel’ had non-zero exit status
The downloaded source packages are in
‘/tmp/RtmpIYbD8J/downloaded_packages’
sessionInfo()
R version 4.0.3 (2020-10-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.1 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
LAPACK: /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_US.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.0.3 magrittr_2.0.1 htmltools_0.5.0 tools_4.0.3 yaml_2.2.1 rmarkdown_2.5
[7] knitr_1.30 xfun_0.19 digest_0.6.27 rlang_0.4.9 evaluate_0.14 purrr_0.3.4
I use 20.04 too and generally have no issue. I usually default to the CRAN builds and have 5.0.2 installed.
Do you have unusual compilers or settings?
Also:
edd@rob:~$ ag -l copy_exception /usr/include/c++/
/usr/include/c++/7/bits/exception_ptr.h
edd@rob:~$ dpkg -S /usr/include/c++/7/bits/exception_ptr.h
libstdc++-7-dev:amd64: /usr/include/c++/7/bits/exception_ptr.h
edd@rob:~$ Does this help? Below I issued your commands, and I also checked the version of /usr/bin/c++. (The strike-through font isn't intentional -- I don't know how to disable the Markdown formatting....)
-
When I issue the commands you show, I get the following:
$ ag -l copy_exception /usr/include/c++/
/usr/include/c++/5/bits/exception_ptr.h <-- YOURS SHOWED ".../c++/7/bits..."
$ dpkg -S /usr/include/c++/5/bits/exception_ptr.h
libstdc++-5-dev:amd64: /usr/include/c++/5/bits/exception_ptr.h -
And, when I check for c++ in R, ">Sys.which('c++')" returns "/usr/bin/c++".
-
Then, from the shell prompt, asking for the version of c++ returns the following:
$ /usr/bin/c++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-17ubuntu120.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu20.04)
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1
$
I noticed that I also have a "9" folder under /usr/include/c++; and get the following:
$ dpkg -S /usr/include/c++/9/bits/exception_ptr.h
libstdc++-9-dev:amd64: /usr/include/c++/9/bits/exception_ptr.h
Should I be using this more up-to-date version of the compiler within R? If so, how do I point R to that?
Actually, as I read the output from the /usr/bin/c++ -v command, it does indicate that I'm using this later version (9).
That should all work. I have g++-7, g++-8, g++-9 and g++-10 here but apparently only the libstdc++-7-dev package I pointed you to earlier. Now it could be that libstd++-9-dev if present is preferred and that it no longer had the header but I doubt that as it would break more build setups.
All this happens at the system level. For R, I only set the compiler as I want to via .R/Makevars (and I described that in a few answers on, say, StackOverflow). In short the file has
VER=
CCACHE=ccache
CC=$(CCACHE) gcc$(VER)
CXX=$(CCACHE) g++$(VER)
CXX11=$(CCACHE) g++$(VER) #-std=c++11
CXX14=$(CCACHE) g++$(VER) #-std=c++14
CXX17=$(CCACHE) g++$(VER) #-std=c++17
SHLIB_CXXLD=$(CCACHE) g++$(VER)
and I sometimes set VER=-10 but right now build with the default g++ which is g++-9.
Also, and I forget the details, the "coupling" between the C++ compiler (g++) and the Standard C++ Library is actually fairly loose. g++ also has its own header which is, seemingly, why I don't have all the various libstdc++-X-dev packages as they are optional.
I renamed my .R/Makevars to .R/Makevars_orig and just for the heck of it, tried to install RcppParallel: It worked!
My Makevars had this as contents:
CC=clang
CXX=clang++ -arch x86_64 -ftemplate-depth-256
CXX14FLAGS=-O3 -march=native -mtune=native -fPIC
CXX14=g++
Something in there must have been the issue.
So, to avoid future problems, do I need some combo of what I had and what you have? Or can I continue without a Makevars file? For example, will things compile without the Makevars but end up running with poorer performance?
I'm doing all of this in order to install package rstan.
By the way, I have a whole bunch of compiler directives set as environment variables from installing conda a while back. Could that be the issue? See below:
$ env | grep "CC|CX|FL"
QT_ACCESSIBILITY=1
GCC_RANLIB=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gcc-ranlib
CXX=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-c++
CXXFLAGS=-fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/apollo/miniconda3/include
DEBUG_CXXFLAGS=-fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -ffunction-sections -pipe -isystem /home/apollo/miniconda3/include
LDFLAGS=-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,--gc-sections -Wl,-rpath,/home/apollo/miniconda3/lib -Wl,-rpath-link,/home/apollo/miniconda3/lib -L/home/apollo/miniconda3/lib
DEBUG_CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -ffunction-sections -pipe -isystem /home/apollo/miniconda3/include
CPPFLAGS=-DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /home/apollo/miniconda3/include
GCC_AR=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gcc-ar
GCC_NM=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gcc-nm
DEBUG_CPPFLAGS=-D_DEBUG -D_FORTIFY_SOURCE=2 -Og -isystem /home/apollo/miniconda3/include
GCC=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-gcc
CC=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-cc
CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe -isystem /home/apollo/miniconda3/include
CXXFILT=/home/apollo/miniconda3/bin/x86_64-conda_cos6-linux-gnu-c++filt
First off, glad to know you have it working.
Second, yes, you broke it. Enabling clang is possible, but it is not the default and it uses the C++ Standard Library differently.
Thirdly, you may want to look into binaries from the 'cran2deb4ubuntu' repo. I talk/blog about that every now and then, here is a post from a few months ago but you can scroll up and down that r4 section and will see multiple example, either using tidyverse or rstan. We now have different wrappers for either "RSPM" (binaries from RStudio, not .deb) or "BSPM" (wrapper to install c2d4u binaries). You could just install my littler package (from CRAN at version 0.3.12, also in Ubuntu 20.04 as 0.3.11: r-cran-littler) and use either of the scripts installRSPM.r or installBSPM.r by just naming the R package i.e.
sudo installBSPM.r rstan
and you're set. I think we can close this as bug report in RcppParallel as there is nothing wrong in RcppParallel.
PS And I keep forgetting rstan is in Ubuntu and Debian too so an even shorter step is just
sudo apt install r-cran-rstan
without the name mapping from R package to binary that RSPM and BSPM do.
Thank you for your help and advice. Much appreciated!
Can you clue me in on what's the difference between installing R packages from CRAN using apt-get at the shell prompt vs. installing R packages from CRAN within R using install.packages()?
At any rate, yes, this is not a bug with RcppParallel, and the issue can be closed.
Thanks again!
Can you clue me in on what's the difference between installing R packages from CRAN using apt-get at the shell prompt vs. installing R packages from CRAN within R using install.packages()?
sudo apt install somepackage installs a binary. It is premade. It is part of the package systeme, knows its system dependencies and installs them. It is generally tested within the distribution and will just work.
In R, saying install.package("somepackage") will (on Linux) generally a source package by, if needed, compiling it. That can run into as you experienced. In short, "binaries tend to be easier on user".
RSPM and BSPM are both ways to give your the benefit of the former ("binaries") by modifying your R setup slightly to have it triggered by the latter. If paragraphs one and two are not crystal-clear, do not worry about the third.
Closing this. It is more common for the person opening the ticket (i.e, you) to close it to signal all it well.
Thanks!
I wish all this was a littler easier "for everybody". I actually find Ubuntu very easy to use but then again I have been on Linux for decades :)
By the way, this all started because my installation of rstan wasn't working -- it would fail during compilation of Stan programs, even though it had worked fine in earlier versions of itself and of R. I uninstalled everything -- RStudio, R, all R packages. Then I had the issue with RcppParallel in reinstalling everything.
Thanks to your help, I got RcppParallel to install again, but rstan still would install but fail during compilation of Stan programs. Googling around, I found that the V8 package was at issue. So I messed around installing/removing/reinstalling (sometimes as binary sometimes as source) that, too.
In all of this, I'd been doing a combo of installing R packages using apt-get (thus the binaries) and installing R packages using install.packages() in R (thus the sources). So, I was skeptical about your suggestion that the binaries via apt-get makes this mess any better.
But finally I figured out what was wrong: When I install binaries using sudo apt-get, the packages reside in "/usr/lib/R/site-library" and show up under "System Library" in RStudio's "Package" pane. And when I install sources using install.packages, the packages reside in "/home/apollo/R/x86_64-pc-linux-gnu-library/4.0" and show up under "User Library" in RStudio. So once I removed rstan, StanHeader, and V8 from "User Library", and kept their binary-installed versions in "System Library", ... Voila!
Everything works fine! Stan programs compile and run without a hitch now, and I'm good to go.
From now on I'm going with the binaries (via sudo apt-get -- and maybe via BSPM or RSPM, in the future).
But, boy, was that a time-consuming lesson -- almost 2 workdays worth -- to learn...
Thanks again.
Yikes. Now you know.
For what it is worth, I am also the Debian maintainer for the r-base package. So when install as a binary for Debian or Ubuntu, you get a few of my digital footprints and design decisions. One of those is/was to disable installations into ~/R/ which I find both confusing and "lossy" -- Linux is multi-user so make packages work for everybody. Anyway... the upshot that yes, a $PATH order matters -- here it is what R shows via .libPaths() which can be set via different variables -- and even there you can dig yourself a hole installing binaries and from source as you need to remember the order and the binaries come last.
All these little details are assumed "known" or learned the hard way. Ah well...