[Bug target/17089] New: Shared libraries always make weak symbols global

["craig dot lawson at centrify dot com" <gcc-bugzilla at gcc dot gnu dot org>]

gcc version 3.2.3 20030502

Shared libraries always make weak symbols global: usually this is desirable. In
some cases, it is not. Like this one:

Developer creates a PAM .so and an NSS .so. Each is written in C++, and each
uses std::basic_string<char>. Each .so defines std::basic_string::c_str() as a
global weak symbol. In most cases, this means that when the .so is loaded into
the process image, c_str() is resolved to the what is defined in the application.

Now consider that c_str() is not defined in the application. The application
loads the PAM .so, and later loads the NSS .so. When the NSS .so loads, it
resolves c_str() to the one defined by the PAM .so. When the application is done
with PAM, it calls pam_end(), which unloads the PAM .so. At some later time, the
NSS code calls c_str(). This, of course, is a disaster, because the code is no
longer in the process image.

Neither gcc nor ld provide a direct means to create a shared library where weak
symbols are not global. My request is that these tools provide some way to turn
weak global symbols into local symbols when the .so is created.

Work around:
  1. Instead of linking all relocatable object files into a shared library, link
them into a new reclocatable object, all.lo (with ld's -i option).
  2. Extract the names of all weak global symbols from all.lo with readelf.
  3. Convert the weak global symbols to locals with objcopy. Objcopy modifies
all.lo in place.
  4. Build the shared library from only all.lo

-- 
           Summary: Shared libraries always make weak symbols global
           Product: gcc
           Version: 3.2.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: craig dot lawson at centrify dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17089