This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: linking problem when using "fopen"


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]