title: Compile with older libc (version `GLIBC_2.14' not found)
body: <p>I have to compile a program on a current ubuntu (12.04). This program should then run on a cluster using CentOS with an older Kernel (2.6.18). I cannot compile on the cluster directly, unfortunately. If I just compile and copy the program without any changes I get the error message "kernel too old". </p>
  
  <p>The way I understood it, the reason for this is not so much the Kernel version, but the version of libc that was used for compilation. So I tried to compile my program dynamically linking the libc from the cluster and statically linking everything else.</p>
  
  <p><strong>Research</strong></p>
  
  <p>There are already a lot of questions about this on SO but none of the answers really worked for me. So here is my research on that topic:</p>
  
  <ul>
  <li><a href="https://stackoverflow.com/questions/6941332/anticipate-kernel-too-old-errors-between-2-6-16-and-2-6-26-kernel-versions">This question</a> explains the reason for the Kernel too old message</li>
  <li><a href="https://stackoverflow.com/questions/10170651/how-do-i-compile-code-for-a-setup-with-older-linux-kernel">This question</a> is similar but more specialized and has no answers</li>
  <li>Linking statically as proposed <a href="https://stackoverflow.com/questions/8127589/run-a-c-executable-in-another-distro">here</a> didn't work because the libc  is too old on the cluster. One answer also mentions to build using the old libc, but doesn't explain how to do this.</li>
  <li><a href="https://stackoverflow.com/questions/2079717/how-do-i-build-an-app-for-an-old-linux-distribution-and-avoid-the-fatal-kernel">One way</a> is to compile in a VM running an old OS. This worked but is complicated. I also read that <a href="http://gcc.gnu.org/ml/gcc/2009-07/msg00299.html" rel="noreferrer">you should not link libc statically</a></li>
  <li><a href="https://stackoverflow.com/questions/2728552/link-to-a-different-libc-file">Apparently</a> it <a href="https://stackoverflow.com/questions/4099013/link-to-provided-glibc">is possible</a> to compile for a different libc version with the option <code>-rpath</code> but this did not work for me (see below)</li>
  </ul>
  
  <p><strong>Current state</strong></p>
  
  <p>I copied the following files from the cluster into the directory <code>/path/to/copied/libs</code> </p>
  
  <ul>
  <li>libc-2.5.so</li>
  <li>libgcc_s.so.1</li>
  <li>libstdc++.so.6</li>
  </ul>
  
  <p>and am compiling with the options <code>-nodefaultlibs -Xlinker -rpath=/path/to/copied/libs -Wl,-Bstatic,-lrt,-lboost_system,-lboost_filesystem -Wl,-Bdynamic,-lc,-lstdc++,-lgcc_s</code></p>
  
  <p>The output of ldd on the compiled binary is</p>
  
  <pre><code>mybin: /path/to/copied/libs/libc.so.6: version `GLIBC_2.14' not found (required by mybin)
  mybin: /path/to/copied/libs/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by mybin)
  linux-vdso.so.1 =&gt;  (0x00007ffff36bb000)
  libc.so.6 =&gt; /path/to/copied/libs/libc.so.6 (0x00007fbe3789a000)
  libstdc++.so.6 =&gt; /path/to/copied/libs/libstdc++.so.6 (0x00007fbe37599000)
  libgcc_s.so.1 =&gt; /path/to/copied/libs/libgcc_s.so.1 (0x00007fbe3738b000)
  /lib64/ld-linux-x86-64.so.2 (0x00007fbe37bf3000)
  libm.so.6 =&gt; /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbe37071000)
  </code></pre>
  
  <p>I'm somewhat confused by the error, because it uses the correct path (i.e. the libc from the cluster) but still complains about a missing glibc version. When running ldd on the cluster it returns <code>not a dynamic executable</code> and running the binary results in the same two errors mentioned above. It also looks like there are other libraries included (linux-vdso.so.1, ld-linux-x86-64.so.2 and libm.so.6). Should I use the older versions for those as well?</p>
  
  <p>So now I have two main questions:</p>
  
  <ul>
  <li>Is this even the correct approach here?</li>
  <li>If yes: how do I link the old libc correctly?</li>
  </ul>