I'm trying to get the newest version of node (12.1.0, at present) running on a CentOS 6.10 box. This is a problem because the standard CentOS binaries are out of date; e.g.:
./node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./node)
(a number of other references like this also appear)
when I try to install and run the binaries, and the g++ / c++ tools are out of date. But I've decided to try to compile from source, if I can get the tools properly aligned.
I've gotten an updated version of the compiler tools from the CERN devtools (http://linux.web.cern.ch/linux/devtoolset), and seemingly have them installed properly. What I've gotten from various places around the web is that I need to export pointers to these new libraries before doing the configure, like:
export CC=/opt/rh/devtoolset-2/root/usr/bin/gcc
export CPP=/opt/rh/devtoolset-2/root/usr/bin/cpp
export CXX=/opt/rh/devtoolset-2/root/usr/bin/c++
These do have the updated and sufficiently modern versions, e.g.,
/opt/rh/devtoolset-2/root/usr/bin/c++ --version
c++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
But they don't seem to be getting into the configuration process:
[root#linux2 node-v12.1.0]# ./configure --prefix=/opt/node-12.1.0
WARNING: C++ compiler too old, need g++ 6.3.0 or clang++ 8.0.0 (CXX=/opt/rh/devtoolset-2/root/usr/bin/c++)
INFO: Using floating patch "tools/icu/patches/64/source/common/putil.cpp" from "tools/icu"
INFO: Using floating patch "tools/icu/patches/64/source/i18n/dtptngen.cpp" from "tools/icu"
WARNING: warnings were emitted in the configure phase
INFO: configure completed successfully
When I cross my fingers and try to make anyway, I get a whole bunch of compilation results and then a bunch of errors, omitted here (for now) for brevity.
Anyway: it's just not working. Can anyone see what's going on here, and how I can get things right? Thanks!
You need a newer devtoolset, 6 or 7 instead of 2. This link should help. And use scl like it suggests instead of setting env vars yourself.
Related
I have installed the devtoolset-10 package on CentOS 7 and run the /opt/rh/devtoolset-10/enable script so that now when I do this:
g++ --version
I get this:
g++ (GCC) 10.2.1 20210130 (Red Hat 10.2.1-11)
Great. Trouble is, the headers under /usr/include/c++ still point to ye olde libstdc++-4.8.5. That is, if I do ls in /usr/include/c++, all I see is:
bash-4.2$ ls /usr/include/c++
4.8.2 4.8.5
What is the magic incantation to "enable" libstdc++-10 to be the default system C++ stdlib?
devtoolset-10
Every g++ comes with it's own headers. /usr/include/c++/4.8* is for 4.8.5 only.
devtoolset-10: g++ version 10 is using the headers at /opt/rh/devtoolset-10/root/usr/include/c++/10
"enable" libstdc++-10
There is no shared library "libstdc++-10". There is /opt/rh/devtoolset-10/root/usr/lib/gcc/x86_64-redhat-linux/10/{ libstdc++.a, libstdc++.so } , where libstdc++.so is a ~200B text file.
I guess the users are supposed to query gcc for the include path.
On my CentOS /usr/include/c++ is not a symlink, and is not supposed to point anywhere, but one can work around that using update-alternatives (I did that only for the compiler itself only, though). Might be overriden by an update, but those don't happen often enough on CentOS.
What is the magic incantation to "enable" libstdc++-10 to be the default system C++ stdlib?
Developer Toolset uses a hybrid linkage model. This means that it does not come with its own libstdc++.so.6, but uses the system version as far as possible. The missing parts are linked statically. This is achieved by the linker script that Knud Larsen mentions.
If you want to compile using headers from the latest C++ compiler you have on Centos7:
Remove your build directory
Export your chosen compiler specifically: export CXX=g++
Thanks to this comment from github:
So, if you try to use nvcc when the system GCC is version 5 and up, you get an "unsupported version" error. But - I've heard people report that they've just commented this out and that CUDA 7.5 "works for them" with GCC 5.x .
When I do the same, however (the check is in $CUDA_DIR/host_config.h), and compile something, I get the following errors:
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/mwaitxintrin.h(36): error: identifier "__builtin_ia32_monitorx" is undefined
/usr/lib/gcc/x86_64-redhat-linux/5.3.1/include/mwaitxintrin.h(42): error: identifier "__builtin_ia32_mwaitx" is undefined
and a bunch of others, but those may be dependent on these. Now, these are MMX-related intrinsics for X86 architectures. I don't use them directly, so I'm guessing they're opted-in somehow. Perhaps this can be avoided?
Is there a way to overcome these errors and actually get GCC 5 to coexist with CUDA 7.5? And for code to build and run?
Notes:
I've read a suggestion to use -D__STRICT_ANSI__. I have, and it doesn't seem to help.
I'm on Fedora 22 in case it matters.
I think a -D_MWAITXINTRIN_H_INCLUDED option should fix the issue. Actually I employed a slightly different approach, commenting out the #include <mwaitxintrin.h> line in x86intrin.h, and successfully built TensorFlow with CUDA 7.5 and GCC 5.2.1.
UPDATE
For the latest version of TensorFlow (v0.8.0), simply choose to use gcc 4.x when invoking the configure script.
Consider installing and temporary selecting an older version of the gcc:
apt-get install gcc-4.8
Then update your alternatives:
update-alternatives --remove-all gcc
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 10
After compiling TensorFlow you can use previous version of gcc calling above command with proper path to /usr/bin/gcc-5.x.
It's essentially futile to try to get GCC 5.x to work with CUDA 7.5 - there are some (or many?) incompatiblity issues which you simply can't resolve. Instead, just upgrade to CUDA 8.0 which has become available since this question was asked.
I had OpenMP compiling and executing in C/C++ on my Mac but then I formatted and reinstalled a fresh copy of OS X. I believe the only difference in the setup was that I had Xcode 5 before the format, and now I have Xcode 6.
Now I get fatal error: 'omp.h' file not found
I read this has something to do with clang and gcc, but, my confusion lies with why did it work before and now its not working?
After some research I seem to have found an answer.
GCC included in the latest version of Xcode (Xcode 6) is only a symbolic link to clang. Since clang does not support OpenMP at this time, you need to install a different version of GCC. The easiest way to do this would be to use Homebrew or MacPorts.
Keep in mind that even when you do this you will probably need to alter your $PATH to have /usr/local come before /usr/bin. This is because Homebrew will have placed your newly installed GCC in /usr/local. Also, some implementations may name the command gcc-49 instead of plain gcc.
Mac OSX uses clang.The gcc compiler in OS X does not support OpenMP. To use this feature a new gcc compiler needs to be installed.
Go to Terminal, if you have not installed Hombrew, install it:
/usr/bin/ruby -e "$(curl -fsSL https://`enter code here`raw.githubusercontent.com/Homebrew/install/master/install)"
then install new version of gcc
brew reinstall gcc --without-multilib
This will not make changes to the existing gcc compiler installed by Xcode as we are reinstalling it.
After running the command given below compile the files using the new version of gcc using the syntax : gcc-version -fopenmp filename.c
To find the version type gcc and then press tab. This will list out all the possible variants of gcc. The version number can be found out from this. For example : gcc-6, gcc-4.9,etc
I'm trying to build a project which is originally written for archlinux. The building process works fine on that archlinux but has a huge amount of errors when I tried to build it on my mac. The project is basically written in C++11 so it's very unstable. I think there has something to do with the compiler because the clang version in mac is 4.2(It actually shows 'Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)' when I type clang --version) and 3.3 for linux. So I want a different version of clang, perhaps 3.3. How Can I specify the version of my compiler when trying to build the project?
Some might argue this belongs on apple.stackexchange.com, but I'm not sure C++11 tags grab a lot of attention there:)
Xcode 5.0 is now available from the App Store. Install it, go to Preferences -> Downloads, and install the Command Line Tools. However...
First, you will need to go to Preferences -> Accounts and add your Apple ID. For some reason, the Command Line Tools download requires an account login. I don't know what the rationale for this is.
> clang -v
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
If you are willing to build from the command line, using make for example (which sounds likely given the project is from Linux), then install Macports and install whatever version of clang you would like:
$sudo port install clang-3.1
$sudo clang_select
Note that this version of clang shouldn't interfere with the Xcode Command Line package if you are will to invoke the Xcode version using xcrun clang instead of plain old clang.
Here's my problem: I want to use C++11 features provided by either gcc or clang. However, I have these requirements:
I'm using a mac
I'm dependent on a bunch of libraries provided by homebrew (and really don't want to compile them myself). Specifically OSG, which itself is dependent on a ton of other libraries. And boost, though I can always compile that myself.
Homebrew seems to only want to use gcc (please correct me if I'm wrong). I can't find any options to switch to LLVM instead. While I understand that this might be due to the fact that not all libraries are compatible with LLVM yet, this would still be a nice feature for those that are.
The version of gcc that comes pre-installed on a mac of gcc is 4.2. gcc 4.2 doesn't have the c++11 features required. I've installed 4.7 via homebrew, but searches for how to set homebrew to use it all say don't do it (gcc 4.2 on the mac is not the vanilla version, so the 4.7 version I got won't be able to compile some things).
My questions are: Does anyone have any suggestions or fixes they have implemented to get around this problem? Should I give up on Homebrew? Does anyone know if Homebrew has a plan to switch to LLVM in the future? Does anyone have any upgrade-plan for how to deal with these incompatibilities?
I don't see how homebrew can continue to depend on gcc 4.2 in the long run, but haven't found any real discussion on this matter.
The default GCC on Mac is not real GCC of GNU. It's LLVM-GCC in fact, which is a branch of GCC. Several years ago, LLVM-GCC was terminated, and replaced with DragonEgg, which is a GCC plugin to use LLVM as a GCC backend.
LLVM-GCC is just a compiler frontend, whose role is using GCC frontend to translate the source code into LLVM IR[Intro to LLVM 11.3]. Once IR generated, LLVM backend will use it to generate binary code. This step has nothing to do with GCC.
The above goal was fully achieved from 10.7, whose components were all compiled by clang, a frontend provided by LLVM.
But Apple still kept LLVM-GCC and GCC runtime libraries. I guess its purpose might be providing a opportunity to compile some code GCC ONLY.
Now let's answer your questions:
If you want to use C++11 features, use clang++ -stc=c++11 -stdlib=libc++ instead. And clang might have already supported all c++11 features.
If you want homebrew supporting LLVM, it has already supported, at least on backend.
If you want homebrew using clang as a compiler frontend, it depends on homebrew community schedule. For example, you can append --with-c++11 argument to use clang to compile boost.But you cannot use this argument when brew install autoconf. In fact, some components might not be compiled correctly by clang.
If you know it can be compiled by clang but homebrew hasn't supported yet, you have to hack the corresponding ruby script at $HOMEBREW_ROOT/Library/Formula directory. Fortunately, in most of cases, replacing ./configure blablabla with ./configure blablabla CXX=clang++ -stc=c++11 -stdlib=libc++ works well. And by the way, if your hack is successful, please make a pull request to homebrew.
So, try it and have a fun.
I have an OS X Mountain Lion environment and use C++11. In this answer I'll break your requirement for not compiling your own stuff.
I use Homebrew and, I must say, I advise you to give up on depending on it to provide you clang and libc++ and all its formulas built with them.
What I've done, and I like, is
clone llvm, clang and libc++ from repositories.
install to /opt/local and put /opt/local/bin at top on /etc/paths.
build my development stuff with my new clang.
let Homebrew for installing tools like git and things I'll not develop for, just use.
I've followed clang build instructions for installing it to /opt/local.
For libc++, one detail: after running the buildit script, I've symlinked the include directory to /opt/local/lib/c++/v1 (clang on /opt/local looks for this as default directory), and also symlinked the libs to /opt/local/lib/ (but look that binaries will not automatically link to libc++ on /opt/local/lib. You must use install_name_tool for that).
use
clang++ -std=c++11 -stdlib=libc++
you can also install latest gcc from homebrew-dups
brew install [flags] https://raw.github.com/Homebrew/homebrew-dupes/master/gcc.rb
For LLVM, brew install --HEAD llvm. To use clang or a brew-installed gcc, add --with-clang or --with-gcc=gcc-x.x where x.x is the version you want.