# Forum: ARM programming with GCC/GNU tools C code porting to arm

 Author: Mithun Mk (mithun) Posted on: 2006-05-05 07:28

Rate this post
 0 ▲ useful ▼ not useful
Hi all,

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
.Can anyone help me in solving this errors.
Mithun

 Author: Martin Thomas (Guest) Posted on: 2006-05-05 11:04

Rate this post
 0 ▲ useful ▼ not useful
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

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

 Author: Mithun Mk (mithun) Posted on: 2006-05-08 08:20

Rate this post
 0 ▲ useful ▼ not useful
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
>
> 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
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'
read':sysread.c:(.text+0x2
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

 Author: Clifford Slocombe (clifford) Posted on: 2006-05-08 12:08

Rate this post
 0 ▲ useful ▼ not useful
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

 Author: Martin Thomas (Guest) Posted on: 2006-05-08 18:43

Rate this post
 0 ▲ useful ▼ not useful
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.

 Author: Clifford Slocombe (clifford) Posted on: 2006-05-08 20:24

Rate this post
 0 ▲ useful ▼ not useful
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

 Author: Martin Thomas (Guest) Posted on: 2006-05-09 07:19

Rate this post
 0 ▲ useful ▼ not useful
Clifford Slocombe wrote:
> 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,

I know that there are different opionions on parallel postings.
free to send questions to any forum or newsgroup he/she can find and it
might be somehow justified if there is a deadline to meet. My opinion is
not that unusual but maybe influenced too much by personal experience
and observations. I have spent a lot of time on answering in forums or
answering e-mails and found out later that the one who has asked the
this happens I feel that I have wasted my (free) time for (free)
"consulting" and I know that I'm not the only one who has made this
experiences.

I hope this explains my opinion.

I'd like to take this opportunity to thank you for your valuable input
to this forum. Your participation is very welcome.

Martin Thomas

 Author: Mithun Mk (mithun) Posted on: 2006-05-09 12:37

Rate this post
 0 ▲ useful ▼ not useful
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,

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

 Author: Clifford Slocombe (clifford) Posted on: 2006-05-09 14:35

Rate this post
 0 ▲ useful ▼ not useful
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

Clifford`

• $formula (LaTeX syntax)$