I was scratching my head over this one for a long time, because libxbase.so definitely does include an out-of-line copy of the destructor (required for the vtable). Eventually I remembered that the destructor can be called in several different ways and that the G++ ABI provides separate entry points, each with its own symbol, for those different cases. These aren't distinguished when demangling, so we must turn that off to see that:
libxbase built with g++ 4.0 has:
0001e940 W _ZN5xbNdxD0Ev // deleting destructor
0001eb30 W _ZN5xbNdxD1Ev // complete object destructor
libxbsql built with g++ 4.0 has:
00015676 W _ZN5xbNdxD1Ev // complete object destructor
00012aec W _ZN5xbNdxD2Ev // base object destructor
libxbase (built with g++ 4.1) has:
0001f850 W _ZN5xbNdxD0Ev // deleting destructor
0001f8e0 W _ZN5xbNdxD1Ev // complete object destructor
0001f960 W _ZN5xbNdxD2Ev // base object destructor
libxbsql (built with g++ 4.1) has:
U _ZN5xbNdxD1Ev // complete object destructor
U _ZN5xbNdxD2Ev // base object destructor
It appears that g++ 4.1 generates out-of-line code for all inline
destructors along with other members of the class and relies on that
avoid generating duplicates elsewhere. But g++ 4.1 is supposed to be
binary-compatible with g++ 4.0 and this behaviour isn't, so this is a
bug in g++.
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
signature.asc
Description: This is a digitally signed message part
