Re: objcopy does not affect STB_GNU_UNIQUE symbols

[Mark Hills <mark dot hills at framestore dot com>]

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 
> loaded.

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 
library.

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++ 
libraries.

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 
result.

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.

[...]
> Cheers
>   Nick
> 

Thanks

-- 
Mark