1

I am a newbie to C++ compilation in production environment I wonder if there are any issues in running a C++11 executable compiled with gcc4.7 ( on debian 6 ) on a computer with an older gcc version, an older glibc / libstdc++.

Thanks

EDIT :

I want to add more details to my question ( maybe it's better to open a new question ? )

I need to compile a legacy C++ code with new libs in C++11

  • on debian 7 ( for gcc 4.7 ) and run the exe on debian 6
  • on fedora 18 ( for gcc 4.7 ) and run the exe on centos 6

How to achieve this ?

user2493964
  • 25
  • 5

1 Answers1

2

It really depends on the system, but in general, for libc, there shouldn't be any real problem, unless you're using some special functions that were only added very recently. One of the design goals of libc is that it remain compatible for all time.

libstdc++ is a different matter, and I would strongly recomment statically linking it (-static-libstdc++).

rubenvb
  • 74,642
  • 33
  • 187
  • 332
James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • 1
    All of glibc, libstdc++ and libgcc are forwards compatible. This means symbols are versioned (or at least should be, you can disable this when building the libraries) and stuff built against an older version will continue to work on systems with newer versions. The inverse however, is not true, even for glibc. – rubenvb Jun 17 '13 at 19:28
  • `libstdc++.so` isn't even present on all machines, so in no case do you want to link it dynamically. And `libc.so` should be both forwards and backwards compatible, unless you use functions which weren't present in the older version; if it's not, it is a serious error. – James Kanze Jun 17 '13 at 23:23
  • 1
    if you compile something on a system with glibc 2.17, it will not work on a system with only glibc 2.13, because a new memcpy was introduced in 2.14 (see e.g. [here](http://stackoverflow.com/questions/8823267/linking-against-older-symbol-version-in-a-so-file)), and the loader will complain it can't find that symbol. That's why building on e.g. Arch is not an option if you want your executable to work on e.g. Debian Stable. – rubenvb Jun 18 '13 at 09:49
  • @rubenvb That sounds like a major defect to me. The whole point of `libc.so` is that it provides an interface which never changes, except for the addition of new functions. – James Kanze Jun 18 '13 at 09:57
  • 1
    and it does: any object compiled on version X of glibc will continue to work with all versions of Y>=X of glibc. For a normative reference on what Linux compatibility means, see the LSB (Linux base System), of which the latest version is 4.1 which specifies [which versions of libc symbols](http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libc.html#REFSTD.LIBC.2), [libgcc_s](http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html) which should be present on all Linux systems. – rubenvb Jun 18 '13 at 10:08
  • And there is a C++ section of LSB 4.1 as well, which shows [libstdc++'s required symbols](http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-CXX-generic/LSB-CXX-generic/baselib.html#LIBSTDCXX) – rubenvb Jun 18 '13 at 10:09