Hi, Mike: Thank you for your help. According to your suggestion, I wrote a simple example and found the cause of the problem. I used "ar" to archive the library, not "arm ar". "ar" cannot build right symbol tables for arm objs. Now I use "arm ar", while linking, symbols can be correctly located. Thank you again. Best regards, Dale -----Original Message----- From: Mike Stump [mailto:mrs@xxxxxxxxx] Sent: 2005年9月16日 12:57 To: Tian Dale-A19565 Cc: gcc-help@xxxxxxxxxxx Subject: Re: problems in C functions call C++ On Friday, September 16, 2005, at 10:01 AM, Tian Dale-A19565 wrote: > Functions (mentioned above, implemented in C++, called by C) were > unresolved, that means the linker cannot locate the implementation of > those functions. > > Could you help me to solve this problem? The ability to answer is dependent upon the quality of the question. If you case you removed all details that allow anyone from helping you. Compare your question to: When I compile: extern "C" void foo() { } I get: .public foo foo: ret at -O2 using gcc 3.4.3 on arm-elf and when I assemble this with binutils 2.904, nm shows no foo in the symbol table, is the compiler broken? Here we see the input to the compiler, the output from the compiler, the compilation flags used and so on... That has an answer, and it is no; further, we could say that as from binutils appears to be broken, and then have you go ask the binutils people about it. So, cut down the testcase to a small example, show us the full source code (gcc -E), the flags used to compile, the .s file produced and the name of the symbol in question...
