This is the mail archive of the
mailing list for the binutils project.
Re: objcopy does not affect STB_GNU_UNIQUE symbols
Hi Nick, thanks for responding.
On Wed, 20 Jul 2016, Nick Clifton wrote:
> > We've hit globally unique (STB_GNU_UNIQUE) that result from libstdc++
> > libraries (tested gcc 5.3.0)
> > 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
I can see the developer of the C++ library has made their intent clear,
but should it not really be in the hands of user of the library to have
final say in the 'scope' of these? This boundary of the process is
somewhat artifical; there may be other boundaries.
Here is, I think, a perfectly valid use case. It also echoes similar
questions I have encountered.
Say we are the publishers of a piece of software which is distributed as a
static library (.a but it could be a .so)
The software is implemented in C++ but exports only a simple "C" API. The
only global symbols are those we expressly make visible after linking the
There are no C++ objects, or exceptions cross our API boundary, and thus
the fact that the library is written in C++ is merely an internal detail
and should remain so.
To keep it an internal detail, and because we're also using a newer
toolchain than our 'customers', we statically link against libstdc++.
Now, with STB_GNU_UNIQUE our library forces unnecessary involvement of
these C++ symbols. If we do expose them, we've no guarantee the semantics
are the same as same-named ones our 'customers' may have in their C++
But in we've now forced a libstdc++ requirement of a new library at
runtime that the target platform may not have.
> If you convert a unique symbol into a local symbol you will destroy this
> requirement, and basically, your C++ code will stop working.
Can you be more specific? By applying the workaround of building the
compiler with --disable-gnu-unique-object, we've been able to keep all
libstdc++ symbols local within our library -- the expected and desired
STB_GNU_UNIQUE is behaving rather like a 'trump card' here, which seems to
have a lot of implications, especially without tools to manipulate it.
My point seems to circle around the toolchain's assumption that the
process address space is the only 'boundary' here. Whereas it's not
unreasonable that a variety of C++-based codepaths should exist in the
same process as long as they are not passing C++ objects between them; and
this is often the case in 'plugin' based applications.
Linux is often criticised for poor binary compatibility, and I'm concerned
as this step appears to further prevent us achieving this in-house, and
commercial software vendors too.