RE: Re: [ECOS] linking problem when using "fopen"

RE: Re: [ECOS] linking problem when using "fopen"

[jyl087]

Jonathan Larmour <jlarmour@redhat.com> wrote:

>jyl087@netscape.net wrote:
>> I'm using GCC 2.95.2. The libgcc.a associated with this compiler
>> implements "new" with exceptions. Robin is on the right track, but
>> the "new (std:nothrow)" form doesn't quite work, as Cyg_Stdio_Stream's
>> constructor doesn't match the std:nothrow form of "new".
>> 
>> Seems like this problem has been known for a couple of years. Why hasn't
>> the fix been incorporated into the source tree?
>
>Sort of because I don't like it because the fault is elsewhere. In
>Ryouzaburou's case, the problem was because of his tools. In your case the
>problem is surely because of your eCos sources (you haven't said what the
>problem exactly is and what eCos sources you are using so I can't be sure).
>I know it "works for me" :-).
>
>I'll do you a deal: tell me what your problem is, and I'll make this change
>even though I don't like it.
>
>Jifl
>-- 

I'm not sure if I'm answering your question correctly, but here's
what I'm doing...

I'm using the GCC 2.95.2 family of tools to cross compile to an ARM
target. Host is RH 7.2. eCos is the latest from the CVS tree.

I have a simple test program which calls "fopen". The program compiles
correctly to produce "test.o". When the linker attemps to build the
"test" executable, I get the errors below. It took me a long time to
figure out what was really happening from the errors shown below. 

Basically, I figured out that the
 "../arm-elf/2.95.2/libgcc.a" contains the "new" implementation,
which is needed by "fopen", and that object code requires all the
C++ cruft for exception handling. That's why the linker is barfing!

Obviously, my libgcc.a is different from yours. I built my tools
using the instructions found on the eCos site, and got these results.
I probably missed a step somewhere to build libgcc clean from C++
exception handling. Is that the case, or is it a matter of the
particular version (2.95.2) that I'm using? 

Let me know if you need further information about my setup. By the
way... do you have any thoughts on my previous query (March 25, 2002)
concerning GDB over serial?

Thanks!
/Jim

----------------------------------------
LINKER ERRORS
----------------------------------------
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(exception.o): In function `__throw_bad_cast':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:321: undefined reference to `bad_cast::~bad_cast(void)'
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:321: undefined reference to `bad_cast virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(exception.o): In function `__throw_bad_typeid':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:327: undefined reference to `bad_typeid::~bad_typeid(void)'
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:327: undefined reference to `bad_typeid virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__throw_type_match_rtti':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:191: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__is_pointer(void *)':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:246: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_ptr':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:46: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_attr':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:58: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_func':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:70: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_ptmf':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:76: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_ptmd':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:82: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:88: more undefined references to `type_info virtual table' follow
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o): In function `__rtti_class':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:50: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o): In function `__rtti_si':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:26: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o): In function `__rtti_user':
/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:11: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:11: undefined reference to `type_info virtual table'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:26: more undefined references to `type_info virtual table' follow
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info node'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info function'
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info node'
collect2: ld returned 1 exit status



__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


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

RE: Re: [ECOS] linking problem when using "fopen"

[Robin Farine]

Hi,

Two more things:

        * in my first message, I forgot to mention that you also need to
          #include <new> which should come from the compiler's own
          header files, i.e. something like
          ".../arm-unknown-elf/gcc-lib/arm-elf/2.95.2/include/new", it
          defines the prototype for the "new (std::nothrow) X(...)"
        * I doubt but there might be a MULTILINK flavor of gcc that
          builds a version of libgcc without the exception related
          stuff?

HTH,

Robin

On Fri, 2002-04-05 at 00:23, jyl087@netscape.net wrote:
> Jonathan Larmour <jlarmour@redhat.com> wrote:
> 
> >jyl087@netscape.net wrote:
> >> I'm using GCC 2.95.2. The libgcc.a associated with this compiler
> >> implements "new" with exceptions. Robin is on the right track, but
> >> the "new (std:nothrow)" form doesn't quite work, as Cyg_Stdio_Stream's
> >> constructor doesn't match the std:nothrow form of "new".
> >> 
> >> Seems like this problem has been known for a couple of years. Why hasn't
> >> the fix been incorporated into the source tree?
> >
> >Sort of because I don't like it because the fault is elsewhere. In
> >Ryouzaburou's case, the problem was because of his tools. In your case the
> >problem is surely because of your eCos sources (you haven't said what the
> >problem exactly is and what eCos sources you are using so I can't be sure).
> >I know it "works for me" :-).
> >
> >I'll do you a deal: tell me what your problem is, and I'll make this change
> >even though I don't like it.
> >
> >Jifl
> >-- 
> 
> I'm not sure if I'm answering your question correctly, but here's
> what I'm doing...
> 
> I'm using the GCC 2.95.2 family of tools to cross compile to an ARM
> target. Host is RH 7.2. eCos is the latest from the CVS tree.
> 
> I have a simple test program which calls "fopen". The program compiles
> correctly to produce "test.o". When the linker attemps to build the
> "test" executable, I get the errors below. It took me a long time to
> figure out what was really happening from the errors shown below. 
> 
> Basically, I figured out that the
>  "../arm-elf/2.95.2/libgcc.a" contains the "new" implementation,
> which is needed by "fopen", and that object code requires all the
> C++ cruft for exception handling. That's why the linker is barfing!
> 
> Obviously, my libgcc.a is different from yours. I built my tools
> using the instructions found on the eCos site, and got these results.
> I probably missed a step somewhere to build libgcc clean from C++
> exception handling. Is that the case, or is it a matter of the
> particular version (2.95.2) that I'm using? 
> 
> Let me know if you need further information about my setup. By the
> way... do you have any thoughts on my previous query (March 25, 2002)
> concerning GDB over serial?
> 
> Thanks!
> /Jim
> 
> ----------------------------------------
> LINKER ERRORS
> ----------------------------------------
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(exception.o): In function `__throw_bad_cast':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:321: undefined reference to `bad_cast::~bad_cast(void)'
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:321: undefined reference to `bad_cast virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(exception.o): In function `__throw_bad_typeid':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:327: undefined reference to `bad_typeid::~bad_typeid(void)'
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/exception.cc:327: undefined reference to `bad_typeid virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__throw_type_match_rtti':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:191: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__is_pointer(void *)':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:246: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_ptr':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:46: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_attr':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:58: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_func':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:70: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_ptmf':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:76: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o): In function `__rtti_ptmd':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:82: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:88: more undefined references to `type_info virtual table' follow
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo2.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo2.cc:300: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o): In function `__rtti_class':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:50: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o): In function `__rtti_si':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:26: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o): In function `__rtti_user':
> /usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:11: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:11: undefined reference to `type_info virtual table'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.h:26: more undefined references to `type_info virtual table' follow
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info node'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info function'
> /usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134: undefined reference to `type_info type_info node'
> collect2: ld returned 1 exit status
> 
> 
> 
> __________________________________________________________________
> Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/
> 
> Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 
> 



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

Re: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

jyl087@netscape.net wrote:
> 
> Basically, I figured out that the
>  "../arm-elf/2.95.2/libgcc.a" contains the "new" implementation,
> which is needed by "fopen", and that object code requires all the
> C++ cruft for exception handling. That's why the linker is barfing!
> 
> Obviously, my libgcc.a is different from yours. I built my tools
> using the instructions found on the eCos site, and got these results.
> I probably missed a step somewhere to build libgcc clean from C++
> exception handling. Is that the case, or is it a matter of the
> particular version (2.95.2) that I'm using?
[snip]
/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134:
undefined reference to `type_info type_info node'
> collect2: ld returned 1 exit status

I've just looked a bit closer at this. I tried a simple test myself with
some genuine 2.95.2 tools:

#include <stdlib.h>

int main(int argc, char *argv[])
{
    int *foo = new int;
    *foo = rand();
    return *foo;
}

Compiled with arm-elf-g++ -fno-exceptions -fno-rtti -ISOMETHING/include
-LSOMETHING/lib  flib.cxx -Ttarget.ld -nostdlib -Wl,-Map,foo

It worked fine, and the linker map includes:
type_info type_info node
                    0x8              
/home/jlarmour/sourceware/gcc/egcs-2.95.2/build/arm-elf/install/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o)

i.e. "type_info type_info node" is defined in tinfo.cc, which makes it all
the more odd that you are seeing an undefined reference from that very
file!

An "arm-elf-nm -C" of the libgcc.a reveals that it should be defined as:
00000008 C type_info type_info node, i.e. a "common" symbol. The same
applies to other symbols that you are having problems with. It would be
interesting to see what it says about your libgcc.a.

So given the same gcc sources, I suspect the real problem here is something
to do with your binutils.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || 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

RE: Re: [ECOS] linking problem when using "fopen"

[jyl087]

Jonathan Larmour <jlarmour@redhat.com> wrote:

>jyl087@netscape.net wrote:
>> 
>> Basically, I figured out that the
>>  "../arm-elf/2.95.2/libgcc.a" contains the "new" implementation,
>> which is needed by "fopen", and that object code requires all the
>> C++ cruft for exception handling. That's why the linker is barfing!
>> 
>> Obviously, my libgcc.a is different from yours. I built my tools
>> using the instructions found on the eCos site, and got these results.
>> I probably missed a step somewhere to build libgcc clean from C++
>> exception handling. Is that the case, or is it a matter of the
>> particular version (2.95.2) that I'm using?
>[snip]
>/usr/local/tools/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o):/usr/local/src/gcc/gcc-2.95.2/gcc/cp/tinfo.cc:134:
>undefined reference to `type_info type_info node'
>> collect2: ld returned 1 exit status
>
>I've just looked a bit closer at this. I tried a simple test myself with
>some genuine 2.95.2 tools:
>
>#include <stdlib.h>
>
>int main(int argc, char *argv[])
>{
>    int *foo = new int;
>    *foo = rand();
>    return *foo;
>}
>
>Compiled with arm-elf-g++ -fno-exceptions -fno-rtti -ISOMETHING/include
>-LSOMETHING/lib  flib.cxx -Ttarget.ld -nostdlib -Wl,-Map,foo
>
>It worked fine, and the linker map includes:
>type_info type_info node
>                    0x8              
>/home/jlarmour/sourceware/gcc/egcs-2.95.2/build/arm-elf/install/H-i686-pc-linux-gnu/lib/gcc-lib/arm-elf/2.95.2/libgcc.a(tinfo.o)
>
>i.e. "type_info type_info node" is defined in tinfo.cc, which makes it all
>the more odd that you are seeing an undefined reference from that very
>file!
>
>An "arm-elf-nm -C" of the libgcc.a reveals that it should be defined as:
>00000008 C type_info type_info node, i.e. a "common" symbol. The same
>applies to other symbols that you are having problems with. It would be
>interesting to see what it says about your libgcc.a.
>
>So given the same gcc sources, I suspect the real problem here is something
>to do with your binutils.
>
>Jifl

Jonathan,

You've gone a bit over my head...  Naturally the above test
of "int *foo = new int" fails on my setup.

By the way, when you say that "type_info type_info node" is declared
in tinfo.cc... do you mean that there is a static var called "node"
of class "type_info" declared? I'm not sure I see that in my tinfo.cc.
What line?

Here's the "arm-elf-nm" dump of my libgcc.a. Only the "tinfo.o"
section is shown. 

Could it be that my binutils were compiled with a flag like
-fvtable-gc that caused my libgcc.a to be incomplete?

Let me know if there's anything else I should try...

Thanks,
/Jim

PS: On another subject - I think my previous difficulties with 
GDB over serial were due to hardware handshaking problems. I'm 
not exactly sure what I did to fix it, but it seems to work now...


---------------------------------------------------tinfo.o:
00000000 t .gcc2_compiled.
00000000 W _._14__si_type_info
00000000 W _._16__user_type_info
00000000 W _._17__class_type_info
00000000 T _._9type_info
00000624 T __14__si_type_infoPCcRC16__user_type_info
0000058c T __16__user_type_infoPCc
00000718 T __17__class_type_infoPCcPCQ217__class_type_info9base_infoUl
         U __builtin_delete
00000028 T __eq__C9type_infoRC9type_info
         U __get_eh_context
00000060 T __rtti_class
00000188 T __rtti_si
000002a4 T __rtti_user
00000000 W __tf14__si_type_info
00000000 W __tf16__user_type_info
00000000 W __tf17__class_type_info
         U __tf9type_info
0000000c C __ti14__si_type_info
0000000c C __ti16__user_type_info
0000000c C __ti17__class_type_info
         U __ti9type_info
00000000 V _vt.14__si_type_info
00000000 V _vt.16__user_type_info
00000000 V _vt.17__class_type_info
         U _vt.9type_info
00000394 T dcast__C14__si_type_infoRC9type_infoiPvPC9type_infoT3
00000370 T dcast__C16__user_type_infoRC9type_infoiPvPC9type_infoT3
00000400 T dcast__C17__class_type_infoRC9type_infoiPvPC9type_infoT3
         U strcmp



__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


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

RE: Re: [ECOS] linking problem when using "fopen"

[jyl087]

Jonathan Larmour <jlarmour@redhat.com> wrote:

>Robin Farine wrote:
>> 
>> On Tue, 2002-04-02 at 00:13, jyl087@netscape.net wrote:
>> > When I use the "fopen" call in my eCos application, I have problems
>> > with linking. It seems that when "fopen_inner" calls "new Cyg_StdioStream"
>> > it drags in all kinds of C++ exception handling cruft. I've verified
>> > that fopen.cxx was compiled with "-fno_rtti -fno_exceptions", but
>> > for some reason, the "new" call drags in all the RTTI and exception
>> > handling stuff.
>> >
>> > I've verified that by commenting out the "new Cyg_StdioStream" call in
>> > "fopen_inner" in the "fopen.cxx" file, my link errors go away, but
>> > obviously fopen no longer works.
>> >
>> > Any ideas?
>> 
>> Using the non-throwing form of operator new might work:
>> 
>>         new (std::nothrow) Cyg_StdioStream(...);
>
>I'm afraid I doubt this will work.
>What C++ cruft does it pull in that causes a problem?
>Jifl


I'm using GCC 2.95.2. The libgcc.a associated with this compiler
implements "new" with exceptions. Robin is on the right track, but
the "new (std:nothrow)" form doesn't quite work, as Cyg_Stdio_Stream's
constructor doesn't match the std:nothrow form of "new".

I found the solution in the ecos-discuss archives from Ryouzaburou
Suzuki - 

  http://source.redhat.com/ml/ecos-discuss/2000-11/msg00235.html

Seems like this problem has been known for a couple of years. Why hasn't
the fix been incorporated into the source tree?

/Jim


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/


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