title: gcc linking shared library works, but dlopen of the same shared lib fails
body: <p>I have a project that looks like this:</p>
  
  <pre><code>executable
      \---&gt; bsp.so
             |---&gt; bsp_protobuf.a
             \---&gt; protobuf.a
  </code></pre>
  
  <p>Where there are two static libraries that get build first (the two protobuf ones) that are statically linked into the bsp.so shared lib. And then finally bsp.so is linked into executable.</p>
  
  <p>When I link executable and link bsp.so using <code>gcc</code> on the command line it links ok.</p>
  
  <p>However if I <strong>dont</strong> link bsp.so then it also builds fine - this is by design - because I want to use <code>dlopen()</code> to determine if I need this library or not (I have pointers to the objects, but none that are instantiated etc...).</p>
  
  <p>The problem I have is that when I use <code>dlopen()</code> (in the code) it fails to open the library due to an undefined symbole. The symbol in question lives within the static librarys.</p>
  
  <p>What I really struggle to understand is why it works on the command line but does not work when I use <code>dlopen()</code> and runtime.</p>
  
  <p>I have 3-4 other shared libs that I can successfully use <code>dlopen()</code> on - so I know my general process for using <code>dlopen()</code> is good.</p>
  
  <p>I am using <code>dlerror()</code> to get the undefined symbol error message out.</p>
  
  <p>I have looked at the following links:</p>
  
  <p><a href="https://stackoverflow.com/questions/7253801/how-to-force-symbols-from-a-static-library-to-be-included-in-a-shared-library-bu">how-to-force-symbols-from-a-static-library-to-be-included-in-a-shared-library-bu</a></p>
  
  <p><a href="https://stackoverflow.com/questions/2222162/how-to-apply-fvisibility-option-to-symbols-in-static-libraries">how-to-apply-fvisibility-option-to-symbols-in-static-libraries</a></p>
  
  <p>I tied the <code>-Wl,--whole-archive</code> idea, but that seemed to pull in too much and the build failed with soooo many warnings - probably somthing more to do with the google protobuf stuff, plus I am not sure that is the approach I want to end up with.</p>
  
  <p>I checked that my shared lib was built with <code>-fPIC</code>, I am not sure if the static libs are build with <code>-fPIC</code> or if they need to be?</p>
  
  <p>I also looked here: </p>
  
  <p><a href="https://gnu.huihoo.org/libtool-1.4.2/html_chapter/libtool_9.html" rel="nofollow noreferrer">libtool_9.html</a></p>
  
  <p>which discusses how to link with <code>dlopen()</code> but this is using libtools - we don't have that for all of our targets so I don't want to use libtools.</p>
  
  <p>I am really not sure which way to progress - it feels like this should be a simple fix somewhere - but as I say, I can't get my head around why one method works and the other does not...</p>
  
  <p><strong>Update</strong></p>
  
  <p>So, after Sam's comment I started to look in the right place. It turns out the makefile for bsp.so statically links only one of the two libraries. 
  There is a seperate tester for that shared lib that links both libraries (and so the tester works) and I had no reason to suspect that lib was broken... well, I learnt quite alot about dlopen and linking etc... :o</p>