title: Problem getting the GNU linker (ld) to export a symbol
body: <p>I am using certain GNU tools, i.e. the GNU C++ Compiler (g++) and the GNU Linker (ld) to create a shared library (.so) file as well as a binary executable file.</p>
  
  <p>The binary executable file makes use of the <code>dlopen</code> function to dynamically load the shared library file at runtime. In addition to this, the shared library file
  needs to invoke a particular class method (called <code>ToolboxManager::registerToolbox</code>) which is defined within the binary executable. This is accommodated by forcing the binary
  executable to export the class method, which in turn is accomplished at link time by linking the binary executable with the following command line options ;</p>
  
  <pre><code>-Wl,--dynamic-list=${top_srcdir}/dynamic_symbol_table.txt
  </code></pre>
  
  <p>where the file <code>${top_srcdir}/dynamic_symbol_table.txt</code> contains the following content ;</p>
  
  <pre><code>{
    extern "C++"
    {
      "ToolboxManager::registerToolbox*";
    };
  };
  </code></pre>
  
  <p>Note the use of the asterisk (*) in the file to force the linker to export all symbols that begin with <code>ToolboxManager::registerToolbox</code>.</p>
  
  <p>When I run the GNU nm utility (<code>nm -C -g ./a.out</code>) on the resulting binary executable, it displays the following information about the afore-mentioned class method ;</p>
  
  <pre><code>08053da0 T ToolboxManager::registerToolbox  
             (  
              std::string&amp;,  
              std::string&amp;,  
              std::map  
              &lt;  
               std::string,  
               Factory_DSPB_Base*,  
               std::less  
               &lt;  
                std::string  
               &gt;,  
               std::allocator  
               &lt;  
                std::pair  
                &lt;  
                 std::string const,  
                 Factory_DSPB_Base*  
                &gt;  
               &gt;  
              &gt;&amp;  
             )
  </code></pre>
  
  <p>or, if the nm utility is invoked as above, but this time without the use of the -C command line switch ;</p>
  
  <pre><code>08053da0 T _ZN14ToolboxManager15registerToolboxERSsS0_RSt3mapISsP17Factory_DSPB_BaseSt4lessISsESaISt4pairIKSsS3_EEE
  </code></pre>
  
  <p>So far, this looks fine. The "T" in front of the definition of the class method <code>ToolboxManager::registerToolbox</code>, denotes that the method resides within the Text/Code section of the file.</p>
  
  <p>Similarly, if I run the nm utility (<code>nm -C -g ./toolbox.so</code>) on the shared library file, it displays the following information about the same afore-mentioned class
  method ;</p>
  
  <pre><code>U ToolboxManager::registerToolbox
    (
     std::string&amp;,
     std::string&amp;,
     std::map
     &lt;
      std::string,
      Factory_DSPB_Base*,
      std::less
      &lt;
       std::string
      &gt;,
      std::allocator
      &lt;
       std::pair
       &lt;
        std::string const,
        Factory_DSPB_Base*
       &gt;
      &gt;
     &gt;&amp;
    )
  </code></pre>
  
  <p>This also looks fine. The "U" in front of the definition of the class method <code>ToolboxManager::registerToolbox</code>, denotes that the method is undefined in the shared library file.</p>
  
  <p>However, a problem occurs when I run the binary exectable from the command line and this problem results in the following error message being displayed ;</p>
  
  <pre><code>./toolbox.so: undefined symbol: _ZN14ToolboxManager15registerToolboxERSsS0_RSt3mapISsP17Factory_DSPB_BaseSt4lessISsESaISt4pairIKSsS3_EEE
  </code></pre>
  
  <p>The mangled class method name which appears in this runtime message is shown below, as the first of the two lines. For comparison purposes, the mangled class method name from above (and which was generated using the the <code>nm -g</code> command) is shown below as the second of the two lines ; </p>
  
  <pre><code>_ZN14ToolboxManager15registerToolboxERSsS0_RSt3mapISsP17Factory_DSPB_BaseSt4lessISsESaISt4pairIKSsS3_EEE
  
  _ZN14ToolboxManager15registerToolboxERSsS0_RSt3mapISsP17Factory_DSPB_BaseSt4lessISsESaISt4pairIKSsS3_EEE
  </code></pre>
  
  <p>As can be seen, the two mangled names are identical. Therefore, I cannot understand why the undefined symbol cannot be resolved at runtime.</p>
  
  <p>I then re-linked the binary executable, however this time I replaced the following linker command ;</p>
  
  <pre><code>-Wl,--dynamic-list=${top_srcdir}/dynamic_symbol_table.txt
  </code></pre>
  
  <p>with the this one ;</p>
  
  <pre><code>-Wl,--export-dynamic
  </code></pre>
  
  <p>The <code>--export-dynamic</code> linker option instructs the GNU Linker to add all the symbols to the dynamic symbol table.</p>
  
  <p>If then ran the binary executable again. This time it executed
  correctly and the call to the dlopen function did not result in an undefined symbol error. This has me utterly perplexed, as it looks as though the symbol is being exported
  correctly in the initial version of the binary executable. Is anyone able to see the problem here? Any assistance would be immensely appreciated.</p>
  
  <p>Thanks in advance.</p>