function reference from standard library

[Kai Ruottu]

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.