title: Why does ld need -rpath-link when linking an executable against a so that needs another so?
body: <p>I'm just curious here. I have created a shared object:</p>
  
  <pre><code>gcc -o liba.so -fPIC -shared liba.c
  </code></pre>
  
  <p>And one more shared object, that links against the former one:</p>
  
  <pre><code>gcc -o libb.so -fPIC -shared libb.c liba.so
  </code></pre>
  
  <p>Now, when creating an executable that links against <code>libb.so</code>, I will have to specify -rpath-link to ld so it can find <code>liba.so</code> when discovering that <code>libb.so</code> depends on it:</p>
  
  <pre><code>gcc -o test -Wl,-rpath-link,./ test.c libb.so
  </code></pre>
  
  <p>otherwise ld will complain.</p>
  
  <p>Why is it, that ld MUST be able to locate <code>liba.so</code> when linking <code>test</code>? Because to me it doesn't seem like ld is doing much else than confirming <code>liba.so</code>'s existence. For instance, running <code>readelf --dynamic ./test</code> only lists <code>libb.so</code> as needed, so I guess the dynamic linker must discover the <code>libb.so -&gt; liba.so</code> dependency on its own, and make it's own search for <code>liba.so</code>.</p>
  
  <p>I'm on an x86-64 GNU/Linux platform, and the main()-routine in <code>test</code> calls a function in <code>libb.so</code> that in turn calls a function in <code>liba.so</code>.</p>