Martin Thomas wrote:
> Mithun mk wrote:
>
>>  I have a c code to be ported to arm.Iam using the GNU tool
>> cahain(WinARM).When iam linking the objects created by the
>> arm-elf-gcc(version 4.1.0) using ld,iam getting errors like
>> "undefined refernce to _modsi3,_divsi3,_sbrk_o,_nedf2,_adddfr3
>
> Check the command-line options to the linker. It seems libc (-lc) and/or
> libgcc (-lgcc) is/are missing. The "missing" sbrk is a FAQ: please read
> the WinARM readme-file or search this forum.
>
> Martin Thomas

Dear Martin,

I have included the commandline options you specified,the errors get
reduced,
but still iam getting errors given below

E:\WinARM\arm-elf\lib\libc.a(freer.o): In function
`_malloc_trim_r':mallocr.c:(.
text+0x48): undefined reference to `_sbrk_r'
:mallocr.c:(.text+0x64): undefined reference to `_sbrk_r'
:mallocr.c:(.text+0x84): undefined reference to `_sbrk_r'
E:\WinARM\arm-elf\lib\libc.a(fseek.o): In function
`_fseek_r':fseek.c:(.text+0x1
58): undefined reference to `_fstat_r'
:fseek.c:(.text+0x1b0): undefined reference to `_fstat_r'
E:\WinARM\arm-elf\lib\libc.a(makebuf.o): In function
`__smakebuf':makebuf.c:(.te
xt+0x3c): undefined reference to `_fstat_r'
E:\WinARM\arm-elf\lib\libc.a(mallocr.o): In function
`_malloc_r':mallocr.c:(.tex
t+0x424): undefined reference to `_sbrk_r'
:mallocr.c:(.text+0x4cc): undefined reference to `_sbrk_r'
E:\WinARM\arm-elf\lib\libc.a(stdio.o): In function
`__sclose':stdio.c:(.text+0xc
): undefined reference to `_close_r'
E:\WinARM\arm-elf\lib\libc.a(stdio.o): In function
`__sseek':stdio.c:(.text+0x30
): undefined reference to `_lseek_r'
E:\WinARM\arm-elf\lib\libc.a(stdio.o): In function
`__swrite':stdio.c:(.text+0x8
4): undefined reference to `_lseek_r'
:stdio.c:(.text+0xac): undefined reference to `_write_r'
E:\WinARM\arm-elf\lib\libc.a(stdio.o): In function
`__sread':stdio.c:(.text+0xd0
): undefined reference to `_read_r'
E:\WinARM\arm-elf\lib\libc.a(sysclose.o): In function
`close':sysclose.c:(.text+
0xc): undefined reference to `_close_r'
E:\WinARM\arm-elf\lib\libc.a(syslseek.o): In function
`lseek':syslseek.c:(.text+
0x24): undefined reference to `_lseek_r'
E:\WinARM\arm-elf\lib\libc.a(sysopen.o): In function
`open':sysopen.c:(.text+0x2
c): undefined reference to `_open_r'
E:\WinARM\arm-elf\lib\libc.a(sysread.o): In function
`read':sysread.c:(.text+0x2
4): undefined reference to `_read_r'
E:\WinARM\arm-elf\lib\libc.a(syswrite.o): In function
`write':syswrite.c:(.text+
0x24): undefined reference to `_write_r'
E:\WinARM\arm-elf\lib\libc.a(time.o): In function
`time':time.c:(.text+0x1c): un
defined reference to `_gettimeofday_r'
E:\WinARM\arm-elf\lib\libc.a(vfprintf.o): In function
`_vfprintf_r':vfprintf.c:(
.text+0x6c4): undefined reference to `__ltdf2'
:vfprintf.c:(.text+0x810): undefined reference to `__nedf2'
:vfprintf.c:(.text+0x838): undefined reference to `__eqdf2'
:vfprintf.c:(.text+0x1354): undefined reference to `__eqdf2'
:vfprintf.c:(.text+0x1904): undefined reference to `__nedf2'
E:\WinARM\arm-elf\lib\libc.a(dtoa.o): In function
`_dtoa_r':dtoa.c:(.text+0x2c4)
: undefined reference to `__nedf2'
:dtoa.c:(.text+0x42c): undefined reference to `__ltdf2'
:dtoa.c:(.text+0x450): undefined reference to `__nedf2'
:dtoa.c:(.text+0x490): undefined reference to `__ltdf2'
:dtoa.c:(.text+0x7e8): undefined reference to `__ltdf2'
:dtoa.c:(.text+0x8dc): undefined reference to `__gtdf2'
:dtoa.c:(.text+0x8f8): undefined reference to `__ltdf2'
:dtoa.c:(.text+0x9ac): undefined reference to `__ltdf2'
:dtoa.c:(.text+0x9dc): undefined reference to `__ltdf2'
:dtoa.c:(.text+0xad0): undefined reference to `__gtdf2'
:dtoa.c:(.text+0xb08): undefined reference to `__ltdf2'
:dtoa.c:(.text+0xbc4): undefined reference to `__gedf2'
:dtoa.c:(.text+0xc54): undefined reference to `__gtdf2'
:dtoa.c:(.text+0xc70): undefined reference to `__eqdf2'
:dtoa.c:(.text+0xcf4): undefined reference to `__nedf2'

Can you suggest me where the problem is.
Regards
Mithun

Mithun mk wrote:
> I have included the commandline options you specified,the errors get
> reduced,
> but still iam getting errors given below
>

All of the references suffixed _r are the stubs that link the standard
library to your target platform (the syscalls). You have to provide
these as part of your BSP. See the newlib documentation for details.
Example syscall modules for a number of reference platforms are provided
with WinARM.

All the __xxxf2 sysmbols are related to floating point handling. They
are defined in libgcc.a (-lgcc).

It would be helpful if you included that actual linker invokation in
your log rather than just the error messages. The order in which the
libraries are linked is also critical unless you group them. The linker
will not by default itereate through libraries to resolve symbols, so
when an unresolved symbol is encountered, its definition must have
previously been encountered in a previous library. Grouping allows a set
of libraries to be checked iteratively to resolve links in any order or
circular dependencies. This is slightly less efficient that just getting
the link order right in the first place, but unless the build is large
(and it seldom is on a microcontroller), you won't notice. I use the
following:

--start-group -lc -lm -lgcc -lstdc++ --end-group

You won't need -lstdc++ if you are not using C++.

Clifford

Martin Thomas wrote:
> It's not very polite to post a question to serveral places at the same
> time (comp.sys.arm and here and maybe somewhere else). Wait some time
> (at least a day) for answers from a forum/newsgroup before asking at
> another place.

That's an intersting take on netiquette; I've never heard that one
before and would have to strongly disagree. If someone has an issue to
resolve and a deadline to meet I'd say that it was legitimate to seek an
answer from any and all possible resources - in parallel. It is not IMO
reasonable to assume that all ARM related forums are occuied by the same
people - because they are not. I for one have never used comp.sys.arm,
so he'd have not had the benefit of my input ;-).

Clifford

Clifford Slocombe wrote:
> Mithun mk wrote:
>> I have included the commandline options you specified,the errors get
>> reduced,
>> but still iam getting errors given below
>> > > All of the references suffixed _r are the stubs that link the standard
> library to your target platform (the syscalls). You have to provide
> these as part of your BSP. See the newlib documentation for details.
> Example syscall modules for a number of reference platforms are provided
> with WinARM.
> --start-group -lc -lm -lgcc -lstdc++ --end-group
> You won't need -lstdc++ if you are not using C++.
>
> Clifford

Dear clifford,

As per your suggestion while linking i included the system call
functions and  was able to reduce the errors.
But still there are errors(given below).can you suggest me where  the
problem is.
I invoked the linker using : arm-elf-ld --output=1.elf --startgroup -lc
-lm -lgcc --end-group

_write_r.o: In function `_write_r':E:\WinARM\bin/_write_r.c:103:
undefined refer
ence to `device_table'
_ioctl_r.o: In function `_ioctl_r':E:\WinARM\bin/_ioctl_r.c:75:
undefined refere
nce to `device_table'
image.o: In function `init_picture':E:\WinARM\bin/image.c:1111:
undefined refere
nce to `ftime'
image.o: In function `exit_picture':E:\WinARM\bin/image.c:1327:
undefined refere
nce to `ftime'
_open_r.o: In function `_open_r':E:\WinARM\bin/_open_r.c:156: undefined
referenc
e to `device_table'
_read_r.o: In function `_read_r':E:\WinARM\bin/_read_r.c:84: undefined
reference
 to `device_table'
_close_r.o: In function `_close_r':E:\WinARM\bin/_close_r.c:71:
undefined refere
nce to `device_table'
E:\WinARM\arm-elf\lib\libc.a(assert.o): In function
`__assert':assert.c:(.text+0
x24): undefined reference to `abort'
E:\WinARM\arm-elf\lib\libc.a(exit.o): In function
`exit':exit.c:(.text+0x28): un
defined reference to `_exit'
E:\WinARM\arm-elf\lib\libc.a(makebuf.o): In function
`__smakebuf':makebuf.c:(.te
xt+0x110): undefined reference to `isatty'

Regards
Mithun

Martin Thomas wrote:
> I hope this explains my opinion.
It does. It can sometimes seem that people are in a panic, asking
questions of everyone and not apparently listening to the answers! I can
see how that would appear impolite. Every case on its merit I think; I
am undecided about this one ;-)

Clifford