Re: undefined symbol: __dso_handle with current CVS breaks C++

[Chip Salzenberg <chip at valinux dot com>]

According to Andreas Jaeger:
> ./a.out: error in loading shared libraries: /data/builds/build-gcc/i686/i686-pc-linux-gnu//libstdc++/libstdc++-libc6.1-2.so.3: undefined symbol: __dso_handle

There is some discussion on the binutils list about this problem.

In short, ld and ld.so don't agree on how to handle "hidden" symbols.
That shouldn't be surprising, since ".hidden" is a brand-new feature.

The easy workaround is probably to tell gcc that ".hidden" isn't
available.  (make sure "HAVE_GAS_HIDDEN" is undefined)

Or if you feel like rebuilding your libbfd, you could use this patch:

=======================================================================

This bug is complex to explain, but the fix is very simple.
It's severity "important" because it breaks libstdc++-v3 on
i386-elf (and probably all other elf targets).

Index: bfd/elflink.c
*************** _bfd_elf_link_record_dynamic_symbol (inf
*** 239,243 ****
  	  
  	  h->elf_link_hash_flags |= ELF_LINK_FORCED_LOCAL;
! 	  break;
  	  
  	default:
--- 239,243 ----
  	  
  	  h->elf_link_hash_flags |= ELF_LINK_FORCED_LOCAL;
! 	  return true;
  	  
  	default:


Here's the long version:

  1.  When a symbol is marked '.hidden' or '.internal', it's not
      supposed to be visible outside the given program / shared
      object.

  2.  The context of the above patch is the forcing of hidden/internal
      symbols to be considered "local" instead of "global".  This is a
      kludge, but a required one, per this comment in elflink.c:

      /* XXX: The ABI draft says the linker must turn hidden and
         internal symbols into STB_LOCAL symbols when producing the
         DSO. However, if ld.so honors st_other in the dynamic table,
         this would not be necessary.  */

  3.  The function in question is responsible for registering symbols
      in the dynamic linkage symbol table.  It gets called because a
      symbol that's hidden/internal will be global in the object file.

  4.  However, by definition, a hidden/internal symbol should _NEVER_
      be in the dynamic linkage symbol table!

  5.  Without the patch, the function does its work, the linker
      creates a reference to the now-local symbol, which (being local)
      can never satisfy this reference.  Thus, the shared object is
      thoroughly broken and unusable.

  6.  The Fix:  This patch forces an immediate return out of the
      function, before the incorrect symbol registration.  This leaves
      the hidden/internal symbol as it should be: 100% private.

I hope this is clear enough.  I'll provide test cases on request.

=======================================================================
-- 
Chip Salzenberg              - a.k.a. -              <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K