So I'm currently trying to compile something with a newer version of g++ (4.7) than the version of CentOS 6.5.
I'm running supports through yum. I've got a 4.7 g++ binary ready to go, and switched the linking so that /usr/bin/g++ links to the binary I want.
This has been working, but now g++ can't find any of the c++ standard libraries (for instance <algorithm> and <iostream>).
I was wondering how g++ loads these libraries / where these libraries are kept so I can figure out how to get them to properly import!
Thanks!
If you have multiple installations of GCC you can direct the gcc|g++ frontend (/usr/bin/{gcc|g++})
to use the tools, headers and libraries of any of them by means
of the -Bprefix
option, where prefix is an installation prefix.
For example, I have GCC 4.9.3 installed (per distro) with prefix:
/usr/lib/gcc/x86_64-linux-gnu/4.9.3
and also have GCC 5.2.1 installed (also per distro) with prefix:
/usr/lib/gcc/x86_64-linux-gnu/5.2.1
If I invoke:
gcc -B/usr/lib/gcc/x86_64-linux-gnu/4.9.3...
then I'm using the 4.9 tools, headers and libraries. If I invoke:
gcc -B/usr/lib/gcc/x86_64-linux-gnu/5.2.1...
then I'm using the 5.2 tools, headers and libraries. If I omit
-Bprefix then I get my latest installation (5.2).
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:
I am running Linux CentOS 7.3 which comes with g++ 4.8.5. I would like to use g++ 7.1.0 to compile some C++ software. But the C++ program compiled with g++ 7.1.0 is using the headers from the standard library that comes with g++ 7.1.0 and the libstdc++.so which also comes with it which make things really painful.
Is there a way to use g++ 7.1.0 and still use the standard library (both headers and libstdc++.so) from g++ 4.8.5 installed with CentOS?
Is there a way to use g++ 7.1.0 and still use the standard library (both headers and libstdc++.so) from g++ 4.8.5 installed with CentOS?
Don't do that (the ABI of libstdc++ from GCC 4.8 & GCC 7 are likely to be different). Instead consider perhaps linking the C++ standard library (from GCC 7.1) statically (and other libraries dynamically, notably those in C including libc.so, not C++).
BTW, how did you get g++-7.1? You could consider compiling GCC 7 (from its source code) on your CentOS 7 (or get some packaged version of it), then you'll have the right libstdc++
Read more about shared libraries, e.g. read Drepper's paper How To Write Shared Libraries and learn more about the -rpath option passed to ld (often using -Wl,-rpath to g++).
The libstdc++ ABI changed between gcc4 and gcc5 so that's not going to work. If you are using gcc7 you should install libstdc++ 7. You can have both versions installed at the same time
Developer Toolset is designed for this scenario, but it is currently at GCC version 6:
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/
Its C++ compiler has been configured in such a way that the programs it compiles are linked dynamically against the system libstdc++, using a backwards-compatible ABI, and only the library code for new C++ features not yet supported by the system library is linked statically. This gives maximum compatibility and allows compiled applications to run without DTS.
I would like to distribute C++ binary that is created by using Eclipse ++ IDE, with the following settings:
Cross GCC Compiler: gcc -std=c++17
Cross G++ Compiler: g++ -std=c++17
Tool Chain settings:
Cross GCC Compiler
Cross G++ Compiler
Cross GCC Linker
Cross G++ Linker
Cross GCC Archiver
Cross GCC Assembler
I am compiling with boost::serilization and have connect that in Linker. The binary is created on Ubuntu 16.04. I tried to run the binary on Ubuntu 14.04, and it give the error:
error while loading shared libraries: libboost_serialization.so.1.58.0: cannot open shared object file: No such file or directory.
I have also installed libboost on the system by using
sudo apt-get install libboost-program-options-dev
But, it gives me the same error.
I think with the above Eclipse IDE setting, it should work in most of the Linux platforms. Is my presumption of its working on most of the Linux platforms wrong??.
When you build your program you link it with specific versions of the shared libraries. On older releases of e.g. Ubuntu those newer versions of the libraries doesn't exist.
If you want to copy the executable between different systems you need to link statically. That means all libraries are linked into the executable so it doesn't rely on shared libraries. It will make the executable bigger of course.
The other week I installed GCC 5.2 from source on my ubuntu machine. I wanted to be able to use fully supported cilk features. Now I would like to revert back to GCC 4.9. How can I uninstall GCC 5.2? I tried using make uninstall but as I understand this is not supported.
I believe you don't need to revert to the system compiler; it is a matter of path. Or set up your $PATH appropriately. Use /usr/bin/g++ for the system compiler, and probably /usr/local/bin/g++ for the compiler you have built from source code from GCC
BTW, you probably could use your GCC 5.2 for almost all your future builds
It depends how you have configured it. You should have configured it with ../gcc-5.2/configure --program-suffix=-my-5.2 then you would use g++-my-5.2 instead of g++
Try to type g++ -v (i.e. probably /usr/local/bin/g++ -v) to understand how it was configured.
You probably could remove the gcc and g++ binaries under /usr/local/bin/ and several other files and directories under /usr/local/ (but be careful).
Indeed, GCC does not support make uninstall
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.