>> - compile and link a program that uses libfoo and libbar with uvw compiler > > Let me follow up with some real result from a minimal test case. > >> (but I'm probably getting the sequence of events totally wrong so please >> specify what is actually going on) > > Not at all. Its a confluence of events, and that's what is making it > tricky to nail down. > > -Wabi-tag is somewhat of a mystery at the moment. Though introduced in > GCC 5.1, its still not documented at 5.3 (cf., > http://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Warning-Options.html#Warning-Options). > According to > http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/, > its intended to catch the mixing and matching that's causing the pain.
I can't really offer anything useful at the moment because I don't have a clear understanding of what's going on. Sorry about that. Here are the three references I am aware. The Red Hat one made my radar tonight: * "GCC5 and the C++11 ABI", http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ * "Dual ABIs", http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html * "The Case of GCC-5.1 and the Two C++ ABIs", http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/ I'm also aware that GCC appears to lack documentation on -Wabi-tag (cf., http://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Warning-Options.html#Warning-Options.). I *thought* -Wabi-tag could be used to detect the differences between ABIs when compiling and linking. That would, in turn alert the user, but I'm not sure that was correct. For example, the following warns of an ABI problem even though C++03 does not have this problem: $ cat test.cxx #include <string> std::string foo __attribute__ ((visibility ("default"))); std::string bar __attribute__ ((visibility ("default"))); And: $ g++ -g3 -O2 -Wabi-tag -std=c++03 -shared test.cxx -o test.so test.cxx:3:13: warning: ‘foo’ inherits the "cxx11" ABI tag that ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ (used in its type) has [-Wabi-tag] std::string foo __attribute__ ((visibility ("default"))); ^ In file included from /usr/include/c++/5/string:52:0, from test.cxx:1: /usr/include/c++/5/bits/basic_string.h:71:11: note: ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ declared here class basic_string ^ test.cxx:4:13: warning: ‘bar’ inherits the "cxx11" ABI tag that ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ (used in its type) has [-Wabi-tag] std::string bar __attribute__ ((visibility ("default"))); ^ In file included from /usr/include/c++/5/string:52:0, from test.cxx:1: /usr/include/c++/5/bits/basic_string.h:71:11: note: ‘std::__cxx11::string {aka std::__cxx11::basic_string<char>}’ declared here class basic_string ^ Then, I thought I could side step the problem by building a library with both old and new symbols that coexist as discussed in the Red Hat blog. But I can't seem to get a definitive answer on what it means to coexist, and how to do it. I asked a couple of questions on the GCC Help mailing list. They may help you more than they helped me: * "Why does -Wabi-tag complain when -std=c++03?", https://gcc.gnu.org/ml/gcc-help/2016-03/msg00123.html * "How to provide coexisting std::string's (with and without abi:cxx11) in GCC 5.1 and above?", https://gcc.gnu.org/ml/gcc-help/2016-03/msg00118.html "What a fine mess we're in" comes to mind right about now... Sorry again about not being able to help. Jeff
