1

I have a bunch of software developed on Linux in C++ using g++. The code compiles and runs on both Ubuntu 12.04 and CentOS 5. We have a few older servers still running CentOS 5. Currently I compile for both OSes. I want to start using some C++11 features. These are supported on Ubuntu 12.04 but not CentOS 5.

I am trying to produce executables on Ubuntu for CentOS. Toward that end I have linked all the executables with

-Wl,-rpath,/home/arcamax/lib

That should tell it to look in /home/arcamax/lib for shared libs before the standard locations. I then used 'ldd' on the Ubuntu box to build a list of needed libraries and copied those libs to /home/arcamax/lib on the CentOS box. When I try to run the programs on the CentOS box I get:

When I run ldd on the CentOS5 box I get output like this:

    libcrypto.so.1.0.0 => /home/arcamax/lib/libcrypto.so.1.0.0 (0x00002b3557f54000)
    libpq.so.5 => /home/arcamax/lib/libpq.so.5 (0x00002b355831c000)
    libstdc++.so.6 => /home/arcamax/lib/libstdc++.so.6 (0x00002b3558548000)
    libm.so.6 => /home/arcamax/lib/libm.so.6 (0x00002b3558849000)
    libgcc_s.so.1 => /home/arcamax/lib/libgcc_s.so.1 (0x00002b3558b43000)
    libc.so.6 => /home/arcamax/lib/libc.so.6 (0x00002b3558d59000)
    libpthread.so.0 => /home/arcamax/lib/libpthread.so.0 (0x00002b3559117000)
    libdl.so.2 => /home/arcamax/lib/libdl.so.2 (0x00002b3559334000)
    libz.so.1 => /home/arcamax/lib/libz.so.1 (0x00002b3559538000)
    libssl.so.1.0.0 => /home/arcamax/lib/libssl.so.1.0.0 (0x00002b3559750000)
    libkrb5.so.3 => /home/arcamax/lib/libkrb5.so.3 (0x00002b35599ac000)
    libcom_err.so.2 => /home/arcamax/lib/libcom_err.so.2 (0x00002b3559c7a000)
    libgssapi_krb5.so.2 => /home/arcamax/lib/libgssapi_krb5.so.2 (0x00002b3559e7f000)
    libldap_r-2.4.so.2 => /home/arcamax/lib/libldap_r-2.4.so.2 (0x00002b355a0bd000)
    /lib64/ld-linux-x86-64.so.2 (0x00000035aa800000)
    libk5crypto.so.3 => /home/arcamax/lib/libk5crypto.so.3 (0x00002b355a30d000)
    libkrb5support.so.0 => /home/arcamax/lib/libkrb5support.so.0 (0x00002b355a535000)
    libkeyutils.so.1 => /home/arcamax/lib/libkeyutils.so.1 (0x00002b355a73d000)
    libresolv.so.2 => /home/arcamax/lib/libresolv.so.2 (0x00002b355a942000)
    liblber-2.4.so.2 => /home/arcamax/lib/liblber-2.4.so.2 (0x00002b355ab5e000)
    libsasl2.so.2 => /home/arcamax/lib/libsasl2.so.2 (0x00002b355ad6c000)
    libgssapi.so.3 => /home/arcamax/lib/libgssapi.so.3 (0x00002b355af88000)
    libgnutls.so.26 => /home/arcamax/lib/libgnutls.so.26 (0x00002b355b1c6000)
    libgcrypt.so.11 => /home/arcamax/lib/libgcrypt.so.11 (0x00002b355b482000)
    libheimntlm.so.0 => /home/arcamax/lib/libheimntlm.so.0 (0x00002b355b701000)
    libkrb5.so.26 => /home/arcamax/lib/libkrb5.so.26 (0x00002b355b908000)
    libasn1.so.8 => /home/arcamax/lib/libasn1.so.8 (0x00002b355bb8e000)
    libhcrypto.so.4 => /home/arcamax/lib/libhcrypto.so.4 (0x00002b355be2f000)
    libroken.so.18 => /home/arcamax/lib/libroken.so.18 (0x00002b355c063000)
    libtasn1.so.3 => /home/arcamax/lib/libtasn1.so.3 (0x00002b355c278000)
    libp11-kit.so.0 => /home/arcamax/lib/libp11-kit.so.0 (0x00002b355c48a000)
    libgpg-error.so.0 => /home/arcamax/lib/libgpg-error.so.0 (0x00002b355c69c000)
    libwind.so.0 => /home/arcamax/lib/libwind.so.0 (0x00002b355c8a0000)
    libheimbase.so.1 => /home/arcamax/lib/libheimbase.so.1 (0x00002b355caca000)
    libhx509.so.5 => /home/arcamax/lib/libhx509.so.5 (0x00002b355ccd9000)
    libsqlite3.so.0 => /home/arcamax/lib/libsqlite3.so.0 (0x00002b355cf23000)
    libcrypt.so.1 => /home/arcamax/lib/libcrypt.so.1 (0x00002b355d1c7000)

Note there is one lib, /lib64/ld-linux-x86-64.so.2, that is still being pulled from a system location. I don't know why that is. When I try to run the program I get:

relocation error: /home/arcamax/lib/libgnutls.so.26: symbol time, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference

A few of the programs fail ldd with the message:

not a dynamic executable

Those programs report the same error as the others when I try to run them.

nicktook
  • 154
  • 1
  • 1
  • 8
  • 1
    Transplanting a newer version of libc into an older system is difficult and error-prone. The simplest solution would be to compile everything on a machine with the lowest possible version of libc. Programs compiled this way will run on newer systems with no problem since libc is backward compatible. But there's no compatibility in the opposite direction. – n. m. could be an AI Nov 13 '12 at 20:54
  • If you insist on doing this the opposite way anyway, have a look [here](http://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host) at the accepted answer. You should place libc and the dynamic linker at identical paths on both machines. – n. m. could be an AI Nov 13 '12 at 21:00

1 Answers1

0

Don't compile on the system with the newer glibc. It will be very difficult or impossible to run them on the machine with the older glibc.

Instead you should compile on the older CentOS system and the binaries will happily run on the newer system.

I want to start using some C++11 features. These are supported on Ubuntu 12.04 but not CentOS 5.

No, they're supported by the GCC version that happens to be installed on Ubuntu 12.04, they're not supported by "Ubuntu". Install the same GCC version on the CentOS host and you can use C++11 features when you compile there.

Installing GCC is easy, just read that wiki page, and don't try to replace your system compiler i.e. install to /usr/local or /opt or $HOME or somewhere other than /usr

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521