This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: linking problem when using "fopen"
- From: Jonathan Larmour <jlarmour at redhat dot com>
- To: jyl087 at netscape dot net
- Cc: eCos users <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 09 Apr 2002 18:27:30 +0100
- Subject: Re: [ECOS] linking problem when using "fopen"
- Organization: Red Hat UK Ltd.
- References: <3F0DF4C3.7DDA4628.00067016@netscape.net>
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