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: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

jyl087@netscape.net wrote:
> 
> Jonathan Larmour <jlarmour@redhat.com> wrote:
> 
> 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?

I think it's a side effect of "#pragma implementation "typeinfo"" near the
top.

> 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?

Even if the binutils were compiled that way, it wouldn't affect the way
libgcc builds. If you are using genuine gcc 2.95.2 sources, this should
really just work. Here's my arm-elf-nm -C dump for tinfo.o for comparison
(the -C means to do the C++ name demangling):

tinfo.o:
00000000 t .gcc2_compiled.
00000718 T bad_typeid::~bad_typeid(void)
00000000 W __si_type_info::~__si_type_info(void)
00000000 W __user_type_info::~__user_type_info(void)
00000000 W __class_type_info::~__class_type_info(void)
00000664 T bad_cast::~bad_cast(void)
00000000 T type_info::~type_info(void)
0000068c T bad_typeid::bad_typeid(void)
000007d8 T __si_type_info::__si_type_info(char const *, __user_type_info
const &)
00000740 T __user_type_info::__user_type_info(char const *)
000008cc T __class_type_info::__class_type_info(char const *,
__class_type_info::base_info const *, unsigned long)
000005d8 T bad_cast::bad_cast(void)
0000058c T type_info::type_info(char const *)
         U __builtin_delete
00000028 T type_info::operator==(type_info const &) const
         U __get_eh_context
000005c0 T type_info::operator!=(type_info const &) const
00000060 T __rtti_class
00000188 T __rtti_si
000002a4 T __rtti_user
00000000 W bad_typeid type_info function
00000000 W __si_type_info type_info function
00000000 W __user_type_info type_info function
00000000 W __class_type_info type_info function
00000000 W bad_cast type_info function
         U exception type_info function
00000000 W type_info type_info function
0000000c C bad_typeid type_info node
0000000c C __si_type_info type_info node
0000000c C __user_type_info type_info node
0000000c C __class_type_info type_info node
0000000c C bad_cast type_info node
         U exception type_info node
00000008 C type_info type_info node
00000000 W bad_typeid virtual table
00000000 W __si_type_info virtual table
00000000 W __user_type_info virtual table
00000000 W __class_type_info virtual table
00000000 W bad_cast virtual table
         U exception virtual table
00000000 W type_info virtual table
00000394 T __si_type_info::dcast(type_info const &, int, void *, type_info
const *, void *) const
00000370 T __user_type_info::dcast(type_info const &, int, void *,
type_info const *, void *) const
00000400 T __class_type_info::dcast(type_info const &, int, void *,
type_info const *, void *) const
000005ac T type_info::name(void) const
         U strcmp
         U exception::what(void) const

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

Well if you're happy for now with a workaround for fopen in place, then
fair enough. But there is definitely something iffy with your tools. 2.95.2
sources shouldn't be different from the ones I built. The only suggestion
is that if you have any future problems, to downgrade your binutils sources
and rebuild your gcc from scratch using them.
 
> 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...

Ah good.

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: [ECOS] linking problem when using "fopen"

[Robin Farine]

On Fri, 2002-04-05 at 18:48, Jonathan Larmour wrote:

[...]

> > In this particular case, (new not overridden and no C++ exceptions), I
> > believe that a safe way to do it would first allocate the required space
> > using "new char [sizeof(...)]", and then if this doesn't return 0 then
> > call the placement operator new to actually create the object.
> 
> char's probably bad in case there are alignment issues (future/alternative
> versions of malloc may not align things so generously (i.e. wastefully).
> 

I do not agree, the new expression must return an address correctly
aligned according to ISO/IEC 14882:1998(E) 5.3.4 §10. But that's a
detail and your solution will perfectly do the job.

[...]

Robin



--
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]

Robin Farine wrote:
> 
> On Fri, 2002-04-05 at 10:45, Martin Buck wrote:
> > Jonathan Larmour wrote:
> > > > Using the non-throwing form of operator new might work:
> > > >
> > > >         new (std::nothrow) Cyg_StdioStream(...);
> > >
> > > I'm afraid I doubt this will work.
> >
> > I don't know about this problem here, but wouldn't "new (std::nothrow)"
> > be the correct solution anyway?
> >
> > IIRC, gcc assumes that the standard new always succeeds if it doesn't
> > throw an exception (which it can't in this case due to -fno-exceptions)
> > and calls the constructor without checking the return value from new. So
> > checking for curr_stream == NULL in fopen.cxx is useless because calling
> > Cyg_StdioStream's constructor with a NULL this pointer will most likely
> > already have caused a crash.

I thought that an effect of compiling with -fno-exceptions means that gcc
would automatically use the nothrow variant.

> Yes, good point Martin. However, the class Cyg_StdioStream could
> redefine new to use a preallocated heap and keep one slot for the error
> case for instance. Anyway, it would not return NULL.
> 
> In this particular case, (new not overridden and no C++ exceptions), I
> believe that a safe way to do it would first allocate the required space
> using "new char [sizeof(...)]", and then if this doesn't return 0 then
> call the placement operator new to actually create the object.

char's probably bad in case there are alignment issues (future/alternative
versions of malloc may not align things so generously (i.e. wastefully).

Anyway, I've changed it to allocate with malloc and use placement new
instead now.

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: [ECOS] linking problem when using "fopen"

[Robin Farine]

On Fri, 2002-04-05 at 10:45, Martin Buck wrote:
> Jonathan Larmour wrote:
> > > Using the non-throwing form of operator new might work:
> > >
> > >         new (std::nothrow) Cyg_StdioStream(...);
> > 
> > I'm afraid I doubt this will work.
> 
> I don't know about this problem here, but wouldn't "new (std::nothrow)"
> be the correct solution anyway?
> 
> IIRC, gcc assumes that the standard new always succeeds if it doesn't
> throw an exception (which it can't in this case due to -fno-exceptions)
> and calls the constructor without checking the return value from new. So
> checking for curr_stream == NULL in fopen.cxx is useless because calling
> Cyg_StdioStream's constructor with a NULL this pointer will most likely
> already have caused a crash.

Yes, good point Martin. However, the class Cyg_StdioStream could
redefine new to use a preallocated heap and keep one slot for the error
case for instance. Anyway, it would not return NULL.

In this particular case, (new not overridden and no C++ exceptions), I
believe that a safe way to do it would first allocate the required space
using "new char [sizeof(...)]", and then if this doesn't return 0 then
call the placement operator new to actually create the object.

Robin



-- 
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"

[Martin Buck]

Jonathan Larmour wrote:
> > Using the non-throwing form of operator new might work:
> >
> >         new (std::nothrow) Cyg_StdioStream(...);
> 
> I'm afraid I doubt this will work.

I don't know about this problem here, but wouldn't "new (std::nothrow)"
be the correct solution anyway?

IIRC, gcc assumes that the standard new always succeeds if it doesn't
throw an exception (which it can't in this case due to -fno-exceptions)
and calls the constructor without checking the return value from new. So
checking for curr_stream == NULL in fopen.cxx is useless because calling
Cyg_StdioStream's constructor with a NULL this pointer will most likely
already have caused a crash.

Martin

-- 
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:
> 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://sources.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?

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
-- 
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: [ECOS] linking problem when using "fopen"

[Jonathan Larmour]

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
-- 
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: [ECOS] linking problem when using "fopen"

[Robin Farine]

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(...);

Robin



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

[ECOS] linking problem when using "fopen"

[jyl087]

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?

Thanks,
/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