Selecting from several m68k libc.a

Jeff Johnston jjohnstn@redhat.com
Wed Apr 21 03:11:00 GMT 2004


Vitus Jensen wrote:
> Hello Jeff,
> 
> 
>>Vitus Jensen wrote:
>>
>>>In my build there are several libc.a (and libm.a, libhwdos.a) created
>>>and installed:
>>>
>>>T:\C\coldfire\gcc-m68k\m68k-coff\lib\libc.a
>>>T:\C\coldfire\gcc-m68k\m68k-coff\lib\m5200\libc.a
>>>T:\C\coldfire\gcc-m68k\m68k-coff\lib\m68000\libc.a
>>>T:\C\coldfire\gcc-m68k\m68k-coff\lib\mcpu32\libc.a
>>>T:\C\coldfire\gcc-m68k\m68k-coff\lib\msoft-float\libc.a
>>>
>>>All different :-(
>>>
>>>Using the following linker commands:
>>>STARTUP(hwdos-crt0.o)
>>>OUTPUT_ARCH(m68k)
>>>OUTPUT_FORMAT(srec)
>>>SEARCH_DIR(m68000)
>>>SEARCH_DIR(m68k)
>>>GROUP(-lc -lhwdos)
>>>
>>>T:\C\coldfire\gcc-m68k\m68k-coff\lib\libc.a is used.  But this libc.a
>>>seems
>>>to be created for a different MC68000 brand than DragonBall, I ran into
>>>a
>>>"tst a1" opcode which isn't supported.
>>>
>>>So I would like to try other libcs.  Something compiled for the
>>>original
>>>MC68000.  Which one is it?  And how do I tell the linker to use it?
>>>
>>>Thank you for your help,
>>>    Vitus
>>>
>>>PS: simply copying the file is no solution :-((
>>>
>>
>>The way this is supposed to work is that you specify compile options that
>>the 
>>compiler uses to select the proper library directory.  You should see a
>>bunch of 
>>other subdirectories off of your gcc-m68k\m68k-coff directory.
>>
>>If you run the cross-compiler with the option -print-multi-lib you will
>>see a 
>>list of compiler options and to what directory they match up with.  You
>>can also 
>>specify compiler options and ask it to tell you what subdirectory it is
>>going to 
>>fish out of using the -print-multi-directory option.
> 
> ...
> 
> Thank you, that was part of the solution.  Option is "-m68000" and it links
> now libc.a from the subdirectory "m68000" which should contain usable
> opcodes.
> 
> OK, but it doesn't link libm.a?!?
> 
> STARTUP(hwdos-crt0.o)
> OUTPUT_ARCH(m68k)
> OUTPUT_FORMAT(srec)
> GROUP(-lc -lhwdos -lm)
> 
> Results in:
> ...
> START GROUP
> LOAD \gcc-m68k\m68k-coff\lib\m68000/libc.a
> LOAD \gcc-m68k\m68k-coff\lib\m68000/libhwdos.a
> LOAD \gcc-m68k\m68k-coff\lib\m68000/libm.a
> END GROUP
> ...
> 
> And the linker complains about all math symbols (`__udivsi3' etc), which ARE
> available in libm.a.  No messages about not finding the file libm.a.  What
> is he smoking now??
> 
> Any tips?  Though this could belong to a different mailing list...
> 
> Bye,
>     Vitus
>

It's not the math library that contains __udivsi3.  It is using __udivsi3.  That 
function is part of the libgcc library which belongs to gcc.  You need to add 
-lgcc to your GROUP statement above.  When you see __*div or __*mod, these are C 
operator calls generated by the compiler.  The compiler has a target library 
libgcc which contains implementations of these functions.  On some platforms or 
models, the compiler can simply use assembler so these functions aren't needed.

-- Jeff J.




More information about the Newlib mailing list