From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24052 invoked by alias); 12 Aug 2009 01:34:31 -0000 Received: (qmail 24010 invoked by uid 22791); 12 Aug 2009 01:34:30 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63 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 01:34:23 +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 n7C1YJ402255; Wed, 12 Aug 2009 02:34:19 +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 B53CE3FEB; Wed, 12 Aug 2009 02:34:18 +0100 (BST) Message-ID: <4A821C19.3020407@jifvik.org> Date: Wed, 12 Aug 2009 01:34:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) MIME-Version: 1.0 To: uwe.kindler@cetoni.de Cc: Bart Veer , ecos-devel@sourceware.org Subject: Re: Strange __cxa_pure_virtual problem References: <4A7C118C.20200@cetoni.de> <4A7C1841.6070900@dallaway.org.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; 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/msg00013.txt.bz2 Bart Veer wrote: >>>>>>"John" == John Dallaway writes: > > > John> Hi Uwe (and Bart) > > > > John> Bart, do you have any ideas why your implementation of > John> __cxa_pure_virtual() in CYGPKG_INFRA might be ignored? > > It is not necessarily being ignored. The eCos version of > __cxa_pure_virtual() ends up in libtarget.a, which is part of the same > linker script GROUP() as libsupc++.a. So strictly speaking the linker > is perfectly at liberty to choose one or the other. In fact it isn't. Order is still well-defined. Anything else would be a bug. I believe I've worked out where this problem is coming from. Unresolved symbol searches are not restarted. Which means ld will not return to the start of the library path to look for unresolved symbols - it will just continue from where it already is in the search path at the point the unresolved symbol appears. So something that references __cxa_pure_virtual from somewhere _after_ libtarget.a, won't see the version in libtarget.a. Note this behaviour is not specific to GROUP; it's also true for standard linking. Normally this isn't an issue for symbols within libtarget.a as the symbols are unique. I note this could potentially also affect stuff in infra's delete.cxx and memalloc's malloc.cxx definitions of new/delete if CYGFUN_MEMALLOC_MALLOC_CXX_OPERATORS is on. So it's possible we need a more general solution than just for __cxa_pure_virtual(). But back to uSTL, I'm still not clear how Uwe has hit this. I did request the other day for a linker map file, which may shed some light. That request still stands. My guess is that uSTL is referencing some object in libsupc++ which is in turn referencing __cxa_pure_virtual. But I don't get why uSTL is a factor here when building a test like diag_sprintf1, as the presence of uSTL surely hasn't changed how diag_sprintf1 is built has it? Perhaps Uwe could shed some light. The uSTL package CDL doesn't seem to do anything like turn on -fexceptions or -frtti for example, that I've seen. So we need more information before determining a correct fix (and FAOD, as Bart will know, his workaround would not be appropriate to be checked in). Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine