title: Shipping libstdc++.so.6 with application
body: <p>I want to use gcc 4.8.1 for my application (requires libstdc++.so.6.0.18), however customers only have libstdc++.so.6.0.13. I have been using <code>-static-libgcc -static-stdlibc++</code> for a while now, but my application consists of several dynamically linked libraries and one main application.  This means that when compiling each dynamic library, they must statically compile the standard library, which is redundant and wasteful.  I want to just ship the standard library of my choice with my product, however every time I run my application in an environment like theirs, it always loads the wrong standard library.  It prefers the <code>/usr/lib64/</code> version no matter what I seem to do (it seems to take precedence over <code>LD_LIBRARY_PATH</code>).</p>
  
  <p>Constraints:</p>
  
  <ol>
  <li><p>I'm not allowed to force them to upgrade to a new standard library.</p></li>
  <li><p>I don't want to make the dynamic libraries static.  (I'd be able to statically compile everything into the main app once, but there are some logistical barriers that prevent me from recompiling some libraries into static ones).</p></li>
  </ol>
  
  <p><code>-Wl,-rpath=$(path_to_directory)</code> is a bit dangerous, however it is legal because the customers do source some settings that allow me to set path variables.  However, setting the rpath of my new stdlibc++ doesn't seem to be overriding the default <code>/usr/lib64</code> version.  I still get <code>GLIBCXX</code> errors because it won't use the right library.</p>
  
  <p>Surely there is an elegant solution for this?</p>
  
  <p>Perhaps there is just an error in my procedure.  Here's an example (sorry about the censor, but it's just username stuff):</p>
  
  <pre><code>~/example$ pwd
  /home/username/example
  ~/example$ echo $LD_LIBRARY_PATH
  
  ~/example$ ls
  Makefile  libstdc++.so.6.0.18  test.cpp
  ~/example$ make
  g++ -std=c++11 -Wall -Werror test.cpp -o test
  ~/example$ ldd test
  ./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test)
      linux-vdso.so.1 =&gt;  (0x00007fffe5919000)
      libstdc++.so.6 =&gt; /usr/lib64/libstdc++.so.6 (0x000000390b800000)
      libm.so.6 =&gt; /lib64/libm.so.6 (0x0000003904800000)
      libgcc_s.so.1 =&gt; /lib64/libgcc_s.so.1 (0x000000390b400000)
      libc.so.6 =&gt; /lib64/libc.so.6 (0x0000003904400000)
      /lib64/ld-linux-x86-64.so.2 (0x0000003904000000)
  ~/example$ setenv LD_LIBRARY_PATH /home/username/example
  ~/example$ echo $LD_LIBRARY_PATH
  /home/username/example
  ~/example$ ldd test
  ./test: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test)
      linux-vdso.so.1 =&gt;  (0x00007fff2d3ff000)
      libstdc++.so.6 =&gt; /usr/lib64/libstdc++.so.6 (0x000000390b800000)
      libm.so.6 =&gt; /lib64/libm.so.6 (0x0000003904800000)
      libgcc_s.so.1 =&gt; /lib64/libgcc_s.so.1 (0x000000390b400000)
      libc.so.6 =&gt; /lib64/libc.so.6 (0x0000003904400000)
      /lib64/ld-linux-x86-64.so.2 (0x0000003904000000)
  </code></pre>
  
  <p>Sorry guys, I made a rather dumb mistake...</p>
  
  <pre><code>~/example$ file libstdc++.so.6.0.18 
  libstdc++.so.6.0.18: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
  </code></pre>
  
  <p>Some dweeb built the wrong version of the library, and another dweeb (namely myself) tried using it on a 64-bit machine.  Using <code>LD_LIBRARY_PATH</code> was working all along...</p>