This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: objcopy does not affect STB_GNU_UNIQUE symbols
- From: Nick Clifton <nickc at redhat dot com>
- To: Mark Hills <mark dot hills at framestore dot com>, binutils at sourceware dot org
- Date: Wed, 20 Jul 2016 09:37:58 +0100
- Subject: Re: objcopy does not affect STB_GNU_UNIQUE symbols
- Authentication-results: sourceware.org; auth=none
- References: <1607131723130.7322@sys953.ldn.framestore.com>
Hi Mark,
> We've hit globally unique (STB_GNU_UNIQUE) that result from libstdc++
> libraries (tested gcc 5.3.0)
> objcopy -L _ZNSt10moneypunctIwLb0EE2idE
>
> which the manual states localises all symbols, but in practice does not
> affect the UNIQUE ones (tested binutils 2.25)
True - this is an omission from the manual.
> How can we manipulate these symbol definitions? Or localise them at
> partial-link time?
You can't. The entire point of STB_GNU_UNIQUE symbols is that they
cannot be local. There must always only ever be one copy of the
symbol in the execution space of an application, no matter how many
shared libraries it loads, and no matter when those libraries are
loaded. If you convert a unique symbol into a local symbol you will
destroy this requirement, and basically, your C++ code will stop
working.
A workaround is to avoid using static variables in C++ classes and
inline functions. This should prevent the generation of unique symbols
in the first place.
Cheers
Nick