Re: gcc5 and std::string

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 11 September 2015 at 14:51, PICCA Frederic-Emmanuel wrote:
> just to be sure to understand,
>
> I rebuilt both projects with gcc 5.2 but in one case I got a std::string with the old API
> and in another a symbol with the new CXX11 abi.
>
> I do not try to link a project compiled with the new ABI and a library with old version.
>
> What I understood is that std::string is special because two symbols are emitted on in the normal name space but with the cxx11 abi and one in the __cxx11 namespace.
>
> In pytango the symbol emited by gcc5.2  is the once without the __cxx11 namespace
>
> _ZN5Tango17ranges_type2constIsE3strE -> Tango::ranges_type2const<short>::str
>
> but if I understand correctly this string is cxx11 abi with the same old name mangled.

The symbol shown above doesn't mention std::string so you can't really
say it "is cxx11 abi" because it isn't using any std::string, new or
old. As far as we can tell from the symbol it doesn't depend on
std::string at all.


> So my question now is why in one case the [abi:cxx11] is present (tango)  and not in the other (pytango)

Without seeing how it is declared I can only guess why it doesn't have
the abi-tag.

Is it only forward-declared in pytango and properly defined in tango?

The abi-tag can only be added when the compiler knows that it depends
on another type with the tag, so if pytango only sees a
forward-declaration it can't know that it should have the tag.

You can compile tango with -Wabi-tag to get warnings about entities
that could cause this problem, and to resolve it you can add the tag
explicitly to the declarations e.g.

#ifdef _GLIBCXX_USE_CXX11_ABI
#define TANGO_CXX11_ABI __attribute((abi_tag("cxx11")))
#else
#define TANGO_CXX11_ABI
#endif

namespace Tango
{
  template<class T>
    struct ranges_type2const
    {
      struct TANGO_CXX11_ABI str;
    };
}




> I use the same compiler in both cases. Except that for pytango I am building a python extension and it calls gcc instead of g++.
> But I guess thath gcc is clever enought to understand that this is a c++ file.

Yes.