Bartosz Apanasewicz wrote:
> Mainly because of library libc which doesn't include functions we expect
> they should be there. What do you think about it?

There are a number of functions that the compiler requires because it
uses them in the code it generates regardless of what functions you
explicitly invoke in your code. This includes memcpy, which in this case
is required to do the initialisation of automatic variables, and
__umodsi3, and  __udivsi3 which implement the % and / operators for
unsigned ints in your example.

Because the compiler requires them they are not part of the Newlib
(libc) library but are included in libgcc.a. You mustthere fore include
the linker option -lgcc (before -lc).

Clifford

Clifford Slocombe wrote:
>
> There are a number of functions that the compiler requires because it
> uses them in the code it generates regardless of what functions you
> explicitly invoke in your code. This includes memcpy, which in this case
> is required to do the initialisation of automatic variables, and
> __umodsi3, and  __udivsi3 which implement the % and / operators for
> unsigned ints in your example.
>
> Because the compiler requires them they are not part of the Newlib
> (libc) library but are included in libgcc.a. You mustthere fore include
> the linker option -lgcc (before -lc).
>
> Clifford

Yes. That was the reason why my sources didn't want to be build. I've
read gcc manual, and now I am using other makefile. Before, it was a
makefile from "BasicGNU" example. Now I am using a makefile from
"AT91SAM7 Interrupts Example" from AT91 WinARM projects page. After some
changes the errors don't apear even if I compile the project with option
-thumb (as I wrote in 1st post it helped).

Thanks, very much, Cliford.

Bartek.

I am experiencing a problem with __umodsi3 being undefined at the linker
stage.  I am building for BREW and have 3 static libs.  A builds fine
and it uses the modulus operator.  B builds fine, also uses the modulus
operator and depends on A.  C depends on B and A and does not use the
modulus operator, HOWEVER, it fails to link complaining about use of the
modulus operator in both B and A.

I link with -lgcc and -lm in that order and programming in C++.

I also tried compiling in ARM and in thumb and with interworking, but
got the same linker error messages each time.

Any ideas as to why this might occur for me?

Thanks

Kevin Benton wrote:
> I link with -lgcc and -lm in that order and programming in C++.

You dug up an old and only vaguely related thread. You should probably
have started a new thread.

It is also useful if you copy & paste the actual build log rather than
'describe' it. Then we see exactly how toy invoke the linker and
precisely what the error message is. Easier for you too - you need say
little more.

Anyhow, -lgcc should be linked last. The linker gathers unresolved
symbols as it goes and looks for them in the subsequent listed
libraries. Because many things ultimately rely upon the support code in
libgcc, it must be linked last.

Sometimes there are circular dependencies or you may just not know what
teh dependencies are. In these cases you can group libraries thus:

-( -lgcc -lm -)

or

--start-group -lgcc -lm --end-group

which causes the linker to search in a loop until no new undefined
symbols are created. However on complex large builds reliance on this
can extend the build time unless you happen to get them in the optimum
order.

Clifford

Amazing, changed the order of linking and it builds!  I never realised
the order of the dependancy libs was SOOO important in this respect...
do'h!  Thanks, Clifford and I'll take note of your posting advice,
sorry!