This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Selecting from several m68k libc.a


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]