This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: more __impure_pointer trouble
Here it is (__impure_ptr is never referenced, so i did not paste the
output here). As I said before, I build the tools myself (maybe that's
where the problem comes from. Just for completeness, I give you also the
version of my tools.
Bob
powerpc-eabi-gcc --version
powerpc-eabi-gcc (GCC) 3.2.1
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
powerpc-eabi-ld --version
GNU ld version 2.13.2.1
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
powerpc-eabi-nm -u .obj/vbcom.o | fgrep cxa
powerpc-eabi-nm library/vbcom.a | fgrep cxa
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
U __cxa_pure_virtual
powerpc-eabi-nm library/vbcom_extras.o | fgrep cxa
U __cxa_pure_virtual
powerpc-eabi-nm library/sigc++/install/lib/libsigc++.a | fgrep cxa
U __cxa_pure_virtual
U __cxa_pure_virtual
On Sun, 2003-03-30 at 17:24, Bart Veer wrote:
> >>>>> "Bob" == Bob Koninckx <bob dot koninckx at mech dot kuleuven dot ac dot 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
--
----------------------------------------------------------------------
ir. Bob Koninckx
Katholieke Universiteit Leuven
Division Production Engineering, tel. +32 16 322535
Machine Design and Automation fax. +32 16 322987
Celestijnenlaan 300B bob dot koninckx at mech dot kuleuven dot ac dot be
B-3001 Leuven Belgium http://www.mech.kuleuven.ac.be/pma
----------------------------------------------------------------------
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss