From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11385 invoked by alias); 12 Aug 2009 14:15:45 -0000 Received: (qmail 11209 invoked by uid 22791); 12 Aug 2009 14:15:41 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from virtual.bogons.net (HELO virtual.bogons.net) (193.178.223.136) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Aug 2009 14:15:34 +0000 Received: from jifvik.dyndns.org (jifvik.dyndns.org [85.158.45.40]) by virtual.bogons.net (8.10.2+Sun/8.11.2) with ESMTP id n7CEFU407510; Wed, 12 Aug 2009 15:15:30 +0100 (BST) Received: from [172.31.1.126] (neelix.jifvik.org [172.31.1.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by jifvik.dyndns.org (Postfix) with ESMTP id 954BA3FEB; Wed, 12 Aug 2009 15:15:29 +0100 (BST) Message-ID: <4A82CE7F.9050608@jifvik.org> Date: Wed, 12 Aug 2009 14:15:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: cetoni GmbH - Uwe Kindler Cc: ecos-devel@sourceware.org Subject: Re: Strange __cxa_pure_virtual problem References: <4A827EDC.3030004@cetoni.de> In-Reply-To: <4A827EDC.3030004@cetoni.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-08/txt/msg00015.txt.bz2 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