[Bug target/17089] New: Shared libraries always make weak symbols global
craig dot lawson at centrify dot com
gcc-bugzilla@gcc.gnu.org
Wed Aug 18 22:46:00 GMT 2004
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
More information about the Gcc-bugs
mailing list