From: Jonathan Larmour <jifl@jifvik.org>
To: cetoni GmbH - Uwe Kindler <uwe.kindler@cetoni.de>
Cc: ecos-devel@sourceware.org
Subject: Re: Strange __cxa_pure_virtual problem
Date: Wed, 12 Aug 2009 14:15:00 -0000 [thread overview]
Message-ID: <4A82CE7F.9050608@jifvik.org> (raw)
In-Reply-To: <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
next parent reply other threads:[~2009-08-12 14:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A827EDC.3030004@cetoni.de>
2009-08-12 14:15 ` Jonathan Larmour [this message]
2009-08-19 14:35 cetoni GmbH - Uwe Kindler
2009-08-19 16:05 ` John Dallaway
2009-08-21 14:55 ` Bart Veer
-- strict thread matches above, loose matches on Subject: below --
2009-08-12 17:49 Uwe Kindler
2009-08-12 19:07 ` Bart Veer
2009-08-13 8:00 ` Uwe Kindler
2009-08-19 10:37 ` Bart Veer
2009-08-12 9:10 cetoni GmbH - Uwe Kindler
2009-08-08 6:04 Uwe Kindler
2009-08-07 11:35 cetoni GmbH - Uwe Kindler
2009-08-07 12:04 ` John Dallaway
2009-08-07 13:40 ` Bart Veer
2009-08-07 15:08 ` John Dallaway
2009-08-07 15:42 ` Bart Veer
2009-08-11 9:05 ` Daniel Néri
2009-08-07 16:31 ` Sergei Gavrikov
2009-08-12 1:34 ` Jonathan Larmour
2009-08-05 18:55 Uwe Kindler
2009-08-07 9:35 ` John Dallaway
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A82CE7F.9050608@jifvik.org \
--to=jifl@jifvik.org \
--cc=ecos-devel@sourceware.org \
--cc=uwe.kindler@cetoni.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).