[ECOS] more __impure_pointer trouble

Jonathan Larmour jifl@eCosCentric.com
Sat Mar 29 07:30:00 GMT 2003

Bart Veer wrote:
>>>>>>"Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:
>     Bob> Hi Bart,
>     Bob> I applied your patch to get the __impure_ptr fix in the INFRA
>     Bob> package. pure.cxx is included and when I check libtarget.a
>     Bob> with powerpc-eabi-nm, the function __cxa_pure_virtual is
>     Bob> present.
>     Bob> However, when linking my application with the command
>     Bob> powerpc-eabi-g++
>     Bob> -L/home/bob/software/build/eCos/ec555/vbcom/library/ecos/install/lib
>     Bob> -Wl,-static -Wl,--gc-sections -nostartfiles -nostdlib -Xlinker -Map
>     Bob> -Xlinker vbcom.map -o bin/vbcom.elf .obj/vbcom.o library/vbcom.a
>     Bob> library/vbcom_extras.o -Ttarget.ld
>     Bob> /home/bob/software/build/eCos/ec555/vbcom/library/sigc++/install/lib/libsigc++.a -lsupc++
>     Bob> I still get the unresolved errors for __impure_ptr (i tried
>     Bob> to put -lsupc++) on every possible location on the command
>     Bob> line.
>     Bob> If on the other hand, I change the group statement in the
>     Bob> eCos linker script from GROUP(libtarget.a libgcc.a) to
>     Bob> GROUP(libtarget.a libgcc.a libsupc++.a) and I remove -lsupc++
>     Bob> from the command line, everything links (and appears to run)
>     Bob> fine.
>     Bob> Did I still miss something, or is a patch to powerpc.ld (and
>     Bob> the other target files also necessary) ?
> I thought that all the .ld files had been updated to pull in -lsupc++,
> but this is not the case: only arm.ld, sh.ld and mn10300_am31.ld
> mention libsupc++. I don't know the exact history here, hopefully
> somebody else remembers.

It was "about to change" way back with the libstdc++ work since there was 
going to have to be a lot of work to update individual platforms to 
reflect linker script changes (ouch), but that never happened, so only a 
few ones I was playing with changed. The change in the  .ld scripts is the 
right solution for eCos though.

> As to what is going on, I suspect that vbcom.o, vbcom.a and
> vbcom_extras.o don't contain any pure virtual functions so don't
> reference __cxa_pure_virtual(). Hence that function does not get
> pulled in when -Ttarget.ld is processed. Next libsigc++ is pulled in,
> containing pure virtual functions, so there is now an unresolved
> reference to __cxa_pure_virtual() which gets resolved by the next
> entry, -lsupc++.
> I suggest something like the following:
>   .obj/vbcom.o library/vbcom.a library/vbcom_extras.o \
>   -L/home/bob/.../lib -lsigc++ -Ttarget.ld -lsupc++
> Note the -l for libsigc++, currently you are pulling in everything in
> that library whether it is needed or not.

I thought that was the way it worked too, but I then found out that the 
linker treats .a files as libraries regardless, as if linked with -l.

eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

More information about the Ecos-discuss mailing list