I have a c++ code that is written and compile on my PC and executed on a remote server.
I changed recently my pc ans so set up everything uptodate on it. But now execution of my code on the unchanged server failed with this error:
./ReactionThermo: relocation error: ./ReactionThermo: symbol _ZTINSt8ios_base7failureB5cxx11E, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference
I look a bit on the web and it appears to be gcc fault. And indeed it's on my pc 5.4 and 4.8 on my server. I tried to upgrade it but got following error:
sudo apt-get install gcc-4.9
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
gcc-4.9 : Depends: cpp-4.9 (= 4.9.4-2ubuntu1~14.04.1) but it is not going to be installed
Depends: libgcc-4.9-dev (= 4.9.4-2ubuntu1~14.04.1) but it is not going to be installed
munge : Depends: libmunge2 (= 0.5.11-1ubuntu1) but 0.5.11-1ubuntu1.1 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
I tried the apt-get -f install comand but it's not improving thinks.
Any ideas.
Thanks
PS: I knoz it's look like GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference but I don't want tu downgrade cpp, rather to upgrade it
In general, you need to build C/C++ binaries on the oldest operating system version you want to support, using the system compiler (or other vendor-supported compilers such as the Toolchain Module for SUSE Linux Enterprise Server or Developer Toolset for Red Hat Enterprise Linux). You cannot compile your program on a newer system and copy it to a different environment with an older (or different) operating system release. In simple cases, it might work, but in other cases, you will get dynamic linker failures at run time (like you did), or even silent data corruption.
Furthermore, you should look at build tools such as pbuilder and mock to automate building your software in a well-defined build environment.
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'm trying to build a project (https://wpewebkit.org/) on Debian Buster for armv7 on a x86 host of the same OS.
I am able to successfully install an arm C++ toolchain and I can successfully compile and run trivial applications.
Where I'm stuck is many of the projects I want to compile require many dependencies that I normally install through the OS's package manager (ex apt-get install libjpeg-dev). When cross compiling, it looks like I can just download & make install the sources I need. However, this project has hundreds of dependencies - it would take a long time to download and compile all of them. At the same time, the arm versions of these dependencies already exist in apt for arm.
How can I, on the host system, install the armhf versions of these dependencies and make them available to my cross compiling toolchain? I've tried dpkg add-architecture armhf and then installing via apt-get install libjpeg-dev:armhf but cmake can't seem to find the installed dependencies.
#artless-noise guides were a good jumping off point, but unfortunately most of the guides weren't helpful in accomplishing what I wanted to do (or if they were, they weren't straightforward in explaining how to accomplish what I needed).
What I ended up doing was using qemu-debootstrap
sudo qemu-debootstrap --arch armhf buster /mnt/data/armhf http://deb.debian.org/debian/
And then just using sudo chroot /mnt/data/armhf and I had a functioning shell where I could just apt-get anything I needed, run any scripts and get armhf binaries.
There are many ways to do this. The key concept is that you need a shadow filesystem that mimics the ARM and you need to tell the package build mechanism where they are. There are many distributions variants LTIB is rpm based, Yocto uses BitBake and supports deb, rpm and ipkg. As well you need to differentiate between build tools and deployed binaries. This is an added concept when cross compiling. The only point above is that Ltib, Yocto, buildroot, etc all keep a shadow root files system and some place to keep host/build binaries. Since you have a Debian system, it is best to stick to their tools.
It is possible to install with dpkg --root. And if you have a complete environment, you can chroot arm_root and then build the package there with host binaries but ARM development files (headers and libraries).
The Debian maint-guide is an overview of building debian packages for the normal case. The Debian cross-compile wiki uses the chroot methods and has reference to building with either sbuild or pbuild packages. The schroot package is very nice as it allows you to build the shadow file system without becoming root. It is very easy to destroy your host file system when learning to cross distribution build and I highly recommend this method. Another key difference between the maint-guide and cross wiki is to install the package cross build essentials.
sudo apt-get install build-essential crossbuild-essential-armhf
Otherwise, most everything is the same but building with the chroot shadow ARM filesystem.
Here is a translation for Ubuntu hosts... you need Zenial or better to use the cross-compile debian wiki method. Ie, a Ubuntu x86 Bionic build for raspberry PI or similar. This method takes care of a lot of things for you, especially preventing filesystem corruption by mistake; thank the kind souls at Debian.
The info under nomenclature is quite important,
build means the architecture of the chroot/dpkg/compiler's executable, i.e. the architecture of the build system (called host by cmake/kernel/etc)
host means the architecture of produced executable objects, i.e. the architecture of the host system where these guest objects will run on (called target or sometimes build elsewhere)
target is what the produced executable objects will generate when producing executable objects, i.e. the architecture of the systems the built programs target their results to run on (relevant only for compilers and similar)
People change the names for the same concepts in cross-building and that can be confusing.
Additional info
Kernel cross build
Meson Cross Compilation
Clang cross compile
I am new to x64_86, but forced to use it because RedHat dropped its 32-bit OS support in RHEL 7.x. I have to complile a lot of code, and am not ready to jump to x64 yet (because I do not need 64-bit addresses and do not want to face all related porting issues). So I have considered using -m32 and -mx32, and decided that -mx32 is the best route for me. However, while -m32 works fine on my build machine, when I use -mx32, I get this error:
In file included from /usr/include/features.h:399:0,
from /usr/include/string.h:25,
from zz.cpp:1:
/usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such file or directory
# include <gnu/stubs-x32.h>
^
compilation terminated.
I searched the web for solutions and some links indicate that I have to install some mysterious "multilib" rpms for g++ and gcc, however, I cannot find these anywhere. Others suggest that I have to install Linux in the x32 mode and build libgcc for x32, which sound extreme. Any ideas or leads? Did someone actually try g++ -mx32? Maybe it is not even supported on the RH platform... Thanks!
P.S. In order to get the "-m32" option to work I had to install:
yum install glibc-devel.i686 libgcc.i686 libstdc++-devel.i686 ncurses-devel.i686
This one fails (yum cannot find these RPMs) - allegedly these are required for -mx32 to work:
yum install gcc-multilib g++-multilib
:(
Multilib is indeed your answer, but do not know why your repo does not support it. I installed mine via apt-get:
sudo apt-get install gcc-multilib
Although it uses 64-bit instructions, it uses the 32-bit ABI so annoyingly will not run under WSL (Windows Linux subsystem), which only supports the 64-bit one.
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'm trying to build OPAM within Cygwin in Windows 8. Here is the error information during the configure stage:
configure: error: You must install the Camlp4 pre-processor. On some
operating systems, these are separate packages from the main OCaml
compiler, such as camlp4-extra on Debian.
I've searched cygwin repository using keywords "caml" and installed all the packages provided; however, the configuration still shows this error message. How can I install this Camlp4 pre-processor?
As long as OPAM doesn't work on windows, you can try GODI (windows port). It has basic windows support and you can install the most common packages through it.
I don't think OPAM works with windows quite yet. I've installed it on OSX and Linux and love it. On windows, though, there is a compilation error with unix_waitpid. This is because ocp-build/ocp-build.boot is a binary packaged with the OPAM source that requires the unix_waitpid instead of the win_waitpid function. I'm not exactly sure why they did this. But, after that their could be other issues.
Regarding the camlp4, running setup.exe of cygwin, I was easily able to find ocaml-camlp4 under interpreters. Depending on the tool-chain, I found it easy enough to just use the mingw binaries found through the ocaml website.