On 2016.03.24 at 07:57 -0400, Jeffrey Walton wrote:
> >> Please forgive my ignorance... What is the "coexistence" that is
> >> discussed? Naively, I thought it would have been something like this
> >> contrived example:
> >>
> >> $ cat test.cxx
> >> #include <string>
> >>
> >> std::string foo __attribute__ ((visibility ("default")));
> >> std::string bar __attribute__ ((visibility ("default")));
> >>
> >> $ g++ -g3 -O2 -shared test.cxx -o test.so
> >>
> >> $ nm test.so | grep _Z3
> >> ...
> >> 0000201c B _Z3barB5cxx11
> >> 00002034 B _Z3fooB5cxx11
> >>
> >> $ echo _Z3fooB5cxx11 _Z3barB5cxx11 | c++filt
> >> foo[abi:cxx11] bar[abi:cxx11]
> >> foo bar
> >>
> >> In the above contrived example, foo and bar are in both namespaces.
> >> That is, the symbol coexists and "things just work".
> >
> > Consider the following example:
> >
> > markus@x4 /tmp % cat test.cpp
> > #include <string>
> >
> > struct Test {
> > __attribute__((used)) std::string foo() { return "foo"; };
> > };
> >
> > markus@x4 /tmp % g++ -c test.cpp && nm test.o | grep _ZN4Test
> > 0000000000000000 W _ZN4Test3fooB5cxx11Ev
> > markus@x4 /tmp % clang++ -c test.cpp && nm test.o | grep _ZN4Test
> > 0000000000000000 W _ZN4Test3fooEv
>
> Exactly! How do I get both _ZN4Test3fooB5cxx11Ev and _ZN4Test3fooEv
> into the shared object so both GCC and Clang "just work". I thought
> that's what "coexistence" meant, but it appears to mean something else
> (that I have not been able to nail down).
There is no way to make it work at the moment. You have to wait until
the clang bug gets finally fixed.
--
Markus
