Re: Strange __cxa_pure_virtual problem

cetoni GmbH - Uwe Kindler wrote:
> Hi Jonathan,
> 
> attached ist the linker mapping file ecos.map (zipped) that I picked 
> from folder build/infra/current after build process stopped with the
> __cxa_pure_virtual error.

Thanks. That clears things up.

The reference comes from here:

/opt/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/lib/nointerwork/libsupc++.a(pure.o)
 
/opt/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/lib/nointerwork/libsupc++.a(eh_exception.o) 
(__cxa_pure_virtual)

eh_exception.o (in pure.o) in turn got pulled in because of this:
/opt/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/lib/nointerwork/libsupc++.a(eh_exception.o)
 
/opt/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/lib/nointerwork/libsupc++.a(guard.o) 
(_ZNSt9exceptionD2Ev)

And the real dependency causing the grief is here:

/opt/ecos/gnutools/arm-eabi/bin/../lib/gcc/arm-eabi/4.3.2/../../../../arm-eabi/lib/nointerwork/libsupc++.a(guard.o)
 
/home/Nutzer/ustl_test_0p_nofio_install/lib/libtarget.a(language_cxx_ustl_ustlecos.o) 
(__cxa_guard_release)

So guard.o (in libsupc++) is being pulled in because of a call from 
ustlecos.cpp to __cxa_guard_release (potentially among others). This pulls 
in the entire exception handling machinery, eventually causing 
__cxa_pure_virtual to be referenced, and because of the way ld looks for 
symbols, it will see the version in libsupc++ and use that instead of the 
one in libtarget.a, because libtarget.a comes earlier in the link line.

I don't quite know how ustlecos.cpp has a reference to 
__cxa_guard_release, since I would only expect that dependency if building 
with -fexceptions. And ustlecos.cpp is empty with -fno-exceptions. Have 
you made changes around this area?

Another odd change is that there is a dependency on ustl in something like 
the diag_sprintf1 test anyway. The problem seems to be here:
/home/Nutzer/ustl_test_0p_nofio_install/lib/libtarget.a(language_cxx_ustl_bktrace.o)
 
/home/Nutzer/ustl_test_0p_nofio_install/lib/libtarget.a(language_c_libc_stdio_stream.o) 
(_ZdlPv)

Looks like you have added uSTL stuff into stdio. Since this has a massive 
knock-on effect of dependencies, with tons of stuff being pulled in as a 
result, this seems like a bad idea TBH.

A fairly trivial workaround to the __cxa_pure_virtual issue may be to use 
CYG_REFERENCE_OBJECT with __cxa_pure_virtual directly from ustlecos.cpp, 
if using exceptions. That will cause the version in libtarget.a to be 
pulled in. But first we should find out why ustlecos.cpp is referencing 
__cxa_guard_release. If you haven't made any changes, then maybe a 
disassembly of the .o may clarify.

This doesn't help the new/delete overrides in infra and memalloc packages 
admittedly. Theoretically they could be susceptible to the same sort of 
issue, although I'm not sure it's a practical concern now.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine