title: How do I build binaries for old Linux versions with c++11?
body: <p>We have started using the cross platform build tool tundra2 to build our application binaries on different platforms.  It works very well.</p>
  
  <p>However, now we need to target Ubuntu 10.04.  Unfortunately compiling tundra2 onto Ubuntu 10.04 is not possible without significant rework of the source code as it uses a number of c++11 features which are not available in gcc 4.4.  I'm able to upgrade to a newer gcc but not one that is able to compile the code.</p>
  
  <p>So I thought I'd try and build tundra2 on a newer platform and copy the tundra2 binary onto 10.04.  Unfortunately I get these errors:</p>
  
  <pre><code>(lucid_amd64)matt@blaze:~/dev/OTOY2/extern/tundra2/build$ ./tundra2 
  ./tundra2: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./tundra2)
  ./tundra2: /lib/libc.so.6: version `GLIBC_2.15' not found (required by ./tundra2)
  </code></pre>
  
  <p>I tried static linking g++ with -static-libstdc++ and -static-libgcc options but the error persists. </p>
  
  <p>Which raises the question.  How do you target older platforms with newer compiler features?
  Should I try to compile GCC 4.8 on Ubuntu 10.04?</p>
  
  <hr>
  
  <p>After some reading and learning more about the gnu c linker than I thought I would need to know.  It seems that the function that's causing the dependancy is one called __fdelt_chk introduced in 2.15.
  Something to do with range checking.  I'm going to try to turn that off or implement a dummy for it.  Also memcpy is wanting 2.14 which isn't available on Ubuntu 10.04.</p>
  
  <hr>
  
  <p>EDIT.
  It would seem that there are two common changes introduced in 2.14 and 2.15. 
  In 2.14, I've read that memcpy was been updated to internally be a memmove call.
  In 2.15, memory bounds checks were introduced (which is what that __fdelt_chk) is about.</p>
  
  <p>Appart from that, if the C++ runtime is statically linked there should be no reason a binary can't run on 10.04 and Centos 5.5.</p>
  
  <p>So how do we deal with these?  I've tried the memcpy wrapper but that didn't work for some reason.  It still tried looking for 2.14.  And putting -fno-stack-protector and -U_FORTIFY_SOURCE on the end of the compile and link lines didn't actually remove it.  I'm also linking with other libraries like pthreads so I don't know if perhaps that requires it.</p>
  
  <p>It would seem that searching for solutions to this problem it's actually quite common and no generic solution is shown.  I think I shall try to compile gcc 4.8 on 10.04 and see how that fares.</p>