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.
Related
I have a C++ program which makes use of some C++ standard libraries such as iostream, vector, sstream and so on, and is only about 120 lines of code. By building it on Debian I get a 25KB executable, while when I build it on Windows 11 (both of them with just "g++ main.cpp") I normally get a 3026KB .exe. If instead I type "--shared-libstdc++" alongside g++ on Windows, I get a smaller .exe, merely 290KB.
My question is, why does compiling and linking in a Linux environment automatically do this while on Windows I have to specify it? Is there a drawback to dynamically linking the standard C++ library on Windows that G++ is aware of?
On Windows, I have: gcc version 10.3.0 (tdm64-1)
On Debian, I have: gcc version 11.3.0 (Debian 11.3.0-3)
[Situation]
I'm developing a c++ library. I had a issue with the GLIBCXX version.
Before, I developed on version machine GLIBCXX_3.4.22.
But my library is not working on the target machine which has GLIBCXX_3.4.19.
So, I downgraded gcc version from 5.2.x to 4.8.x and GLIBCXX version from 3.4.22 to 3.4.19.
It successfully ran on the target machine.
But my development machine(ubuntu) boot fails because other libraries can't find GLIBCXX 3.4.22 version which is already linked to that version.
So, I re-installed GLIBCXX 3.4.22 but gcc version is still 4.8.5.
[Question]
Does my library compiled on gcc-4.8.5 not use GLIBCXX_3.4.22 version? Is it fine to develop on this environment (gcc 4.8.5, GLIBCXX_3.4.22)?
What is the relationship between gcc(compile) version and GLIBCXX(GLIBC) version on the linux machine.
Where can I check the correct version compatibility mapping information between gcc and GLIBCXX(GLIBC)?
libstdc++ (which is where the GLIBCXX_* versioned symbols are from) has been ABI compatible from GCC 3.4.0 to now.
Your library will use the latest symbol versions from libstdc++ at the time of compile. The compiler version does not matter, except
GCC 5.1 added C++11 support with a "dual ABI" in libstdc++. Code compiled in C++11 mode will use symbols with the [abi:cxx11] tag, and that may not interoperate with code compiled without C++11 (whether from an older compiler without C++11 support, or a newer compiler set to use an older standard).
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
If you need to build binaries that run on older systems, I would recommend setting up an older distribution inside a container and building in there, with all old libraries. This way, nothing newer from your development system can leak into them.
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).
I know for my class, I had to install cygwin to get my Netbeans IDE running, but I see options during setup for both g++ and gcc and I am not sure if they are the same thing or not, and where does wingw? is it another compiler, and if so why choose on over the other?
g++ and gcc are the gnu C++ and C compiler respectively. They're really the same compiler with different flags though.
MinGW is "Minimalist Gnu for Windows". It's a port of the gnu compiler to run on Windows.
Cygwin is another port of the gnu compiler (and various other utilities) to Windows. More accurately (IMO, anyway), it's leaving the compiler/programs running on POSIX, and porting a POSIX layer to run on Windows.
As to choosing between them: if you're running Linux, you probably want ot just get a package of gcc/g++ for the distro you're using.
If you're running Windows, it'll depend on your intent. Cygwin works well for porting existing Linux/POSIX code to Windows. If, however, you plan to write code, and just want a compiler, I'd go for MinGW instead.
One other note: the MinGW at MinGW.org hasn't been updated in years. If you decide to go with MinGW, I'd advise getting it from nuwen.net instead (it's updated quite regularly).
gcc will compile: .c/.cpp files as C and C++ respectively.
g++ will compile: .c/.cpp files but they will all be treated as
C++ files.
Also if you use g++ to link the object files it automatically
links in the std C++ libraries (gcc does not do this).
gcc compiling C files has less predefined macros.
For wingw, did you mean mingw? Because MinGW is for compatibility with Windows. MinGW uses GCC/G++, and MinGW is not a compiler, it's basically a stripped version of Cygwin that uses MS libs wherever possible.
Depends upon what you are building;
gcc is for C programs.
g++ is for C++ programs.
I've not heard of wingw.
I am working on a cluster which has older version of intel compiler (11) and gcc (4.3).
I have installed a newer trial version of intel composer xe (with 14.0 compiler). I have also installed gcc 4.9. Both the newer gcc and intel compilers are in my home directory (non-root)
I use C++11 in my codes, so obviously i use -std=c++11 flag for compiling. I provide -L and -I flags to include intel's includes and libraries in my makefile
When I try to compile my code with icpc, The compiler looks in /user/include/c++/4.3/.... path.
I tried to remove the path by setting C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to
/home/peter/intel/composerxe/include.
But it still looks in the /usr/include/c++ path. Because of this, the old files in /user/include/c++/4.3/tr1_impl/ ... are included and not the latest ones.
How do I stop the intel compiler to look into these paths and see the new ones. Now instead of intel compiler i use gcc4.9, what changes do i need to make ?
I tried adding -nostdinc flag for compiling, but no luck. It gives error as :
catastrophic error cannot open source file "iostream"
because 1st include header is iostream
I figured out that intel shares its headers from already installed gcc in the system and takes the /usr/include or usr/local/include paths.
In my case, the operating system on our cluster is SUSE linux with gcc4.3 as default GNU compiler.
Now, the cluster management software is set such that two compilers (intel and gcc) cannot be loaded simultaneously (module intel version 11 and module gcc version 4.5)
After I did a gcc --print-search-dirs I found out that the intel compiler inherits some common headers (iostream, etc) from existing gcc compiler (which is 4.3 in this case) and hence includes the old tr1_imple files and headers because of which I get errors in compiling c++11 code.
I did install gcc 4.9 in my home directory, but intel 14 has compatibility issues in including headers from gcc 4.9 and again this time weird compiler errors.
While using gcc 4.5 (using module load gcc-4.5) atleast got me to compile the code, I think the only solution to this problem would be to use gcc 4.7.2 and provide its include path since that was the first release with c++11 support ( not c++0x working draft)implementing a lot of c++11 features except concurrency.
One needs to know that Intel compilers do depend upon existing gcc compiler provided by the OS or installed by the user/root. Without that, they are pretty much of no use.
Cheers!