I have an application that is deployed on a centos 6.7 plateform and built with the native C++ compiler of the distribution, that is gcc 4.4.7. Now for some reasons ( actually, upgrade to Qt 5.7 ), i need to use a modern compiler with C++11 features fully supported, let's say gcc 4.8.2 from devtoolset-2. Another possibility was to built a new version of gcc from the sources. According to https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html the 4.8.3 (but 4.8.2 is not mentionned ) version of gcc is backward compatible with the libstdc++.6.0.13 ( default c++ lib in centos 6.7 ).
I have recompiled the application with this new gcc 4.8.2 version and everything seems to run fine in the dev environment. The app use the default system c++, gcc and c libs.
However, when it comes to deployment on centos 6.7 ( after a fresh install for example ) i ask myself how safe it is to do so ? Instead on relying on ABI compatibility , would it be better to provide the latest C++ and C libraries that are compatible with the version of gcc that was used to build my app ?
Nice to see someone else doing this - I recently started doing it too!
My answer is not very authoritative, but for what it's worth, I rebuild all C++ libraries that I'll be linking against, and deploy those with my application. I also redistribute libstdc++ and libgcc_s, putting them in a special place out of the way (/usr/lib/myApplicationName/...). I ensure that my application links against all of these redistributed libraries instead of whatever's native.
I had a concern that libc compatibility might be a problem, but I haven't found that I need to do anything about any C libraries, or with libc itself.
Update: Turns out I didn't even need to do this, because I'm using devtoolset; FML.
Related
[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.
Not exactly sure where this question belongs, let me know if I should move it.
Here is the issue; over the past years I have a put together a relatively large personal codebase in C++11 that I'm using for work, but my workplace runs supposedly the latest version of RHEL on their cluster, which runs gcc 4.4.7, which supports C++11 only partially.
I have battled to get a decent compiler installed, but apparently there is no easy way of making this happen, so instead I am wondering whether it would be possible to cross-compile C++11 sources on my own desktop, and export the executable on the cluster at my workplace. I just don't know where to start in order to do that:
Is it possible (and how) to cross-compile C++11 sources from Ubuntu to RHEL?
Since I am at it, is it possible to rebuild gcc 4.8 or a suitable libstdc++ (or libc++) entirely from Ubuntu to an rpm package compatible with RHEL?
(Note: I would preferably use clang (3.4) to compile on my desktop, but gcc (4.8) would be fine too.)
I'm running CentOS 6.4 and need a later version of the C++ compiler to build my development tools (Qt Creator in this case).
I'm unclear on the implications of using devtools and I'm hoping someone can explain.
If I compile programs using devtools, does that means the executable will run on other Centos 6.4 installations without change?
Or..do I know have to ship libraries or other files with my compiled programs?
If so...do I have to modify my C++ code to reference the later libraries? or is this something done by the person installing my compiled program
I hope this somewhat late answer can still help you. What I found is that compiling my project with devtoolset (1.1 in my case, but that should not matter too much) on RHEL 6.4 produces binaries which can almost run on a standard RedHat EL 6.4 (should be similar for Centos 6.4).
The only trouble I ran into was compiling my project with -std=c++11, which produced some problems due to incompatible symbols. The reason is that the GCC folks considered these parts of the standard library to be experimental in GCC 4.4, so they broke ABI compatibility in some places.
Turns out, there's an easy fix: Link your programs with the additional command-line-argument -static-libstdc++. That way, the binary becomes a bit larger but is runs on an unmodified RHEL 6.4 without installing additional libraries/updates for the devtoolset.
To answer your questions explicitly:
Yes, almost.
No.
Don't change the code, just add -static-libstdc++ when linking.
Right now I compile my C++ software on a certain old version of linux (SLED 10) using the provided gcc and it can run on most newer versions as they have a newer glibc. Problem is, that old gcc doesn't support C++11 and I'd really like to use the new features.
Now I have some ideas, but I'm sure others have the same need. What's actually worked for you?
Ideas:
Build on a newer system, static link to newer glibc. (Not possible, right?)
Build on a newer system, compile and link against an older glibc.
Build on an older system using an updated gcc, link against older glibc.
Build on a newer system, dynamic link to newer glibc, set RPath and provide our glibc with installer.
As a bonus, my software also support plugins and has an SDK. I'd really prefer that my customers could compile against my libraries without a huge hassle.
Thanks in advance. Ideas welcome, proven solutions preferred.
Build with the newer gcc. Either install the new compiler on the old machine or comile on your new machine and install the necessary dynamic libraries on the old machine.
Note that multiple versions of libc (and also libstdc++) are supported on a single machine since they are typically versioned (i.e. libc.so.5, libc.so.6, etc)
I am new to programming, so have never experienced a language update. With the release of C++11, I want to make use of all the new features such as lambda expressions and threads. I know I can do this with external libraries but using native language features would be more convenient.
I am using gcc 4.2.1 on Mac OS X Snowleopard in Xcode 3.2.6
What all do I need to do and update to start using C++11 features?
You can update to Xcode 4.1 (or whatever the most recent version you can get for Snow Leopard is) and get a new compiler with a few more C++11 features. There are some posts here on Stack Overflow about getting better support for C++11 in Xcode 4.1 on Snow Leopard.
But even the latest compiler available through Xcode does not support some C++11 features like lambdas. To get the best C++11 support you'll want to install a newer compiler, gcc 4.6 or 4.7, or Clang.
I frequently build the latest version of clang from source. It's not difficult to do if you're familiar with building other open source software. I use the git repos for clang and llvm, http://llvm.org/git/llvm.git and http://llvm.org/git/clang.git. You can also find instructions on their website for getting started: http://clang.llvm.org/get_started.html. Once you have the source for clang and llvm it's just ./configure && make && sudo make install. (you might want to run the tests before installing, since this is directly out of the repository. After make do make check in the llvm directory, and once that passes cd down to tools/clang and run make test. If everything is okay then sudo make install)
I don't remember if Snow Leopard included libc++ or not, so you may need to get that as well. http://libcxx.llvm.org/
Once everything is built and installed you can do:
clang++ -std=c++11 -stdlib=libc++ main.cpp && ./a.out
and you should have just about the best C++11 support around.
Recent patches in clang have really improved support for the last features you're likely to notice as a new C++ programmer. There are still a few bits and pieces left, but as of 3.1, and as far as I'm aware, clang has every C++11 feature that either gcc 4.7 or VC++11 has and more besides. libc++ also has the fewest gaps in terms of C++11 standard library features IME (though I think VC++'s standard library will also be pretty complete once they catch up on language features, e.g. char32_t and char16_t as native types so that the standard's mandated specializations for those types can be used).
Basically you only need to get a toolchain that has support for the new features. In macosx that would be either GCC or clang++. You might need to download/compile a particular version if needed (i.e. if the feature that you want to try is not in a prepacked compiler bundle but is available in the repository).
I downloaded and compiled the latest trunk of clang++ from subversion to do some testing, and installed g++ 4.6 with macports in Snow Leopard. I remember that I had some issues with the setup of the environment, but don't quite remember which of the compilers gave me problems or how I solved them. Google is your friend there :)
If you have homebrew installed, from this article, just two steps:
brew tap homebrew/dupes
brew install gcc --enable-cxx --enable-fortran --use-llvm