title: C++ linker missing library when running (SONAME behavior)
body: <p>I've made a program that uses two shared libraries (which I compiled) and are placed like this:</p>
  
  <pre><code>/home_directory_where_I_compile_and_run_everything
  --&gt;/lib/libjson_linux-gcc-4.4.6_libmt.so
  --&gt;/lib/libre2.so.0
  </code></pre>
  
  <p>When I compile my program I pass the relative location of those libraries to the linker, like this:</p>
  
  <pre><code>g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/libre2.so.0
  </code></pre>
  
  <p>And it compiles fine, however when running the program it fails to find libre2.so, and if I inspect it with ldd, here's what happens:</p>
  
  <pre><code>....
  lib/libjson_linux-gcc-4.4.6_libmt.so (0x00007f62906bc000)
  libre2.so.0 =&gt; not found
  ....
  </code></pre>
  
  <p>Apparently, it does acknowledge that the path on libjson is relative, but it doesn't do that on libre2.so.0 (it trims all the path and just leaves libre2.so.0)</p>
  
  <p>Can someone tell me why this happens?</p>
  
  <p>Also, is there a way to modify this via a g++ argument?</p>
  
  <p>Best.</p>
  
  <p><strong>* UPDATE *</strong> Whoa check this out!
  I've changed the name of libre2.so.0 to stuff.so, and then tried to compile essentially the same like this:</p>
  
  <pre><code>g++ ...... stuff ........ my_program.cc lib/libjson_linux-gcc-4.4.6_libmt.so lib/stuff.so
  </code></pre>
  
  <p>And it fails anyways; not only it does fail, it fails because it can't find "libre2.so.0".</p>
  
  <p>Whyyy?</p>
  
  <p><strong>* UPDATE # 2 *</strong></p>
  
  <p>Output for <code>readelf -d the_program.o</code></p>
  
  <pre><code>0x0000000000000001 (NEEDED)             Shared library: [lib/libjson_linux-gcc-4.4.6_libmt.so]
  0x0000000000000001 (NEEDED)             Shared library: [libre2.so.0]
  </code></pre>
  
  <p>Now, if I could just make that [libre2.so.0] to be [lib/libre2.so.0] instead it would be fine.</p>
  
  <p><strong>* UPDATE # 3 *</strong></p>
  
  <p>As @troubadour found out:</p>
  
  <blockquote>
    <p>When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker.</p>
  </blockquote>
  
  <p>That's why it works with libjson.....so and not with libre2.so.0. (libjson.....so does not have an entry for SONAME).</p>
  
  <p>And I finally found the exact question for what I'm looking for:</p>
  
  <p><strong>Is there any way to tell the gcc linker to ignore the SONAME entries on a shared library file and link instead to the specific file path?</strong></p>