title: Installing/updating GLIBC to 2.17 on Raspberry Pi
body: <p>Recently I undertook a project to create static and dynamic versions of a library I use that is written and maintained by another programmer here.  Mostly I did it for the exercise but additional programs will surely find their way to this machine so I figure why not create a dynamic library and save some space on any new executables that will surely use this library.  So a new program was installed to the machine by me today and I had written a shell script to check for missing libraries before I placed it into it's running environment.  On my production/customer system the script generated this message:</p>
  
  <pre><code>/lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.17' not found (required by /usr/local/lib/libUtilityQQ.so)
  </code></pre>
  
  <p>Both my development and production machines are on wheezy and they are both Raspberry Pi 2s.  I'm not sure how I got this libc 2.17 of glibc.  The production pi has libc 2.13, judging from the links in /lib.  I found that /etc/apt/sources.list has been altered on my development box (by me, no doubt) and the machines are running different kernels, but this has never been a problem before.</p>
  
  <p><strong>Main development pi:</strong></p>
  
  <p><em>uname -a</em>:</p>
  
  <pre><code>Linux qfuel-dev 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l GNU/Linux
  </code></pre>
  
  <p><em>/etc/apt/sources.list</em></p>
  
  <pre><code>deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
  deb http://http.debian.net/debian wheezy-backports main
  </code></pre>
  
  <p><strong>Production pi:</strong></p>
  
  <p><em>uname -a</em>:</p>
  
  <pre><code>Linux pa0036 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux
  </code></pre>
  
  <p><em>/etc/apt/sources.list</em></p>
  
  <pre><code>deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
  </code></pre>
  
  <p>So obviously these machines have different kernels.  That could be one method that is open to me to update glibc.(?)</p>
  
  <p>This customer pi is located several states away so I don't know if updating their kernel by me remotely is a good idea or even possible.</p>
  
  <p>Now that I think of it, I have built a new version of g++ recently, but I am not using it, continuting to use 4.6.3.  I'm thinking that a new libc was built along with the compiler code?</p>