[ECOS] more __impure_pointer trouble

[Bart Veer]

>>>>> "Bob" == Bob Koninckx <bob.koninckx@mech.kuleuven.ac.be> writes:

    <snip>
    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.

    <snip>
    >> I suggest something like the following:
    >> 
    >> .obj/vbcom.o library/vbcom.a library/vbcom_extras.o \
    >> -L/home/bob/.../lib -lsigc++ -Ttarget.ld -lsupc++

    Bob> Nope, still get the same link errors ...

    >> 
    >> Note the -l for libsigc++, currently you are pulling in everything in
    >> that library whether it is needed or not. You might also want to think
    >> about changing vbcom.a to libvbcom.a and using -Llibrary -lvbcom,
    >> depending on whether or not it is a real library or just a collection
    >> of object files.

    Bob> Thanks for the tip :-) didn't know these subtle differences

Actually, it looks like I was wrong about this. I have come across
linkers which behaved as I described, but GNU ld seems to be more
sensible.

As to the main problem, I do not understand what is going on. The
linker should now be picking up __cxa_pure_virtual() from eCos rather
than from libsupc++. A simple testcase with a pure virtual function
builds fine for powerpc-eabi, in fact there is no need to link with
-lsupc++ at all. There don't seem to be any uses of
__cxa_pure_virtual() within libsupc++ itself, which might have
confused things. The only other reference to impure_ptr in libsupc++
is in the demangling code so possibly that is getting pulled in, or
there could be references to impure_ptr from elsewhere. Could you try
the following:

  powerpc-eabi-nm -u .obj/vbcom.o | fgrep impure_ptr
  powerpc-eabi-nm -u library/vbcom.a | fgrep impure_ptr
  powerpc-eabi-nm -u library/vbcom_extras.o | fgrep impure_ptr
  powerpc-eabi-nm -u /home/bob/.../libsigc++.a | fgrep impure_ptr

  powerpc-eabi-nm -u .obj/vbcom.o | fgrep cxa_demangle
  powerpc-eabi-nm -u library/vbcom.a | fgrep cxa_demangle
  powerpc-eabi-nm -u library/vbcom_extras.o | fgrep cxa_demangle
  powerpc-eabi-nm -u /home/bob/.../libsigc++.a | fgrep cxa_demangle

(No need for full details, I just want to know which if any of these
files reference _impure_ptr and/or __cxa_demangle).

Changing all but three of the linker scripts at this stage of the 2.0
release process is undesirable, even if it is the correct long-term
solution. It would partially invalidate much of the testing done so
far. We may have to do it, but if we can find some simple workaround
that would be preferable.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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