CODEWITHSUNDEEP
c++linuxgcc
Wqh
Wqh

Reputation: 75

Still need -D_GLIBCXX_USE_CXX11_ABI=0 for c++ projects

When my company upgraded our gcc to 6.3, all the c++ projects were added -D_GLIBCXX_USE_CXX11_ABI=0 for the ABI breakage issue in gcc. Now our gcc are 8.2, that flag is still in the project files. Since there are so many project files, it will not be removed soon. I need to build a third party library that will be linked by those application projects. I know for the reason of consistency, I'd better to use the same flag. But I'm wondering if I don't use it, will I experience any weird behavior of c++ string? Can gcc 8.2 handle this smoothly, no matter you set or not set this flag?

Upvotes: 1

Views: 10769

Answers (2)

Tony Tannous
Tony Tannous

Reputation: 14851

From Dual ABI troubleshooting

If you get linker errors about undefined references to symbols that involve types in the std::__cxx11 namespace or the tag [abi:cxx11] then it probably indicates that you are trying to link together object files that were compiled with different values for the _GLIBCXX_USE_CXX11_ABI macro. This commonly happens when linking to a third-party library that was compiled with an older version of GCC. If the third-party library cannot be rebuilt with the new ABI then you will need to recompile your code with the old ABI.

You have to recompile the whole project and libraries.

Upvotes: 1

Matteo Italia
Matteo Italia

Reputation: 126857

The flag ensures that all the modules have the same ABI for C++ containers; if you link together two modules that use a different ABI, they'll have a different idea of what e.g. an std::string is (how it is laid out in memory, what its methods are, ...).

Mixing modules with different C++ ABIs is in general a bad idea: while, if they run each on its own, without passing C++ containers between them stuff should work, trying to pass e.g. an std::string between these modules will either result in a compilation error (std::string is actually an alias for two different types in the two ABIs, so the mangled names will differ), or, in more subtle cases (e.g. if an std::string is a member of a structure passed between the two modules) you'll get crashes/corruption at runtime.

Upvotes: 0

Related Questions