This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Dony wrote: > Yeah, I suspect also the same, since even main function reference > wasn't found. > > x---------- > main.o(.text+0x18):main.c undefined reference to '__main' > x---------- This '__main()' is a function in 'libgcc.a', which runs C++ global constructors and destructors, not the function 'main()'... A call to this init/exit function is generated to C programs too, so you must use '-lgcc' too. The 'soft-float' routines are also in libgcc, among quite many integer-conversion routines, C++ exception handling, rtti functions and so on... > I don't know what I have done wrong. > I have already included the directory of std. header file > during compiling, and also the library during linking. > My makefile like this : > # Here located all the 'lib*.a' > LIB = c:/gcc-m68k/m68k-coff/lib/m68000 > LDFLAGS = -s -n -Tmsdsl.ld -L$(LIB) Adding the option '-v', or even the '-Wl,-verbose' to your CFLAGS (or '-verbose' to your LDFLAGS, use 'ld --help' to see your 'ld' options), would give you quite a lot more information... Anyhow, I suspect that you must use '-lgcc lc -lgcc -lc' to get the 'strlen' symbol resolved... GNU ld seem not to be able to go backwards in a library file to include routines for unresolved symbols found in the library end... Ok, when one gets unresolved symbols after linking a library file where the routines having the symbols should be, the first thing of course is to make sure that they really are there: D:\usr\local\m68k-elf\lib>..\bin\nm libc.a | grep strlen U strlen U strlen U strlen U strlen U strlen U strlen U strlen strlen.o: 00000000 T strlen <----------- !!!!!! U strlen U strlen U strlen U strlen Ok, the 'strlen' was there, but if I had seen rows: U _strlen U strlen U _strlen strlen.o: 00000000 T _strlen <----------- !!!!!! U strlen U _strlen I know that there are some bug with the function name, and look at the C-library sources to fix it... The 'dirent' routines at 'newlib/libc/sys/sysvi386' seem to have this 'bug' --- some of the function names (opendir(), readdir(), closedir(),...) start with a '_', but others don't. Then there is 'seekdir()' which just calls '_seekdir()'. The 'getcwd()' in 'newlib/libc/unix' uses these '_'-names. So the problem can need some thinking: Are the '_'s there for some reason or are they just bugs... Ok, the 'seekdir()' method seemed to be the solution, just add extra wrappers around those '_'-ones and stop wondering the purpose for them... Cheers, Kai ________________________________________________ To get help for the crossgcc list, send mail to crossgcc-request@cygnus.com with the text 'help' (without the quotes) in the body of the message.