This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: Strange __cxa_pure_virtual problem
- From: Jonathan Larmour <jifl at jifvik dot org>
- To: cetoni GmbH - Uwe Kindler <uwe dot kindler at cetoni dot de>
- Cc: ecos-devel at sourceware dot org
- Date: Wed, 12 Aug 2009 15:15:27 +0100
- Subject: Re: Strange __cxa_pure_virtual problem
- References: <4A827EDC.3030004@cetoni.de>
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