Re: Strange __cxa_pure_virtual problem

Bart Veer wrote:
>>>>>>"John" == John Dallaway <[email protected]> writes:
> 
> 
>     John> Hi Uwe (and Bart)
> 
>     <snip>
> 
>     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