Re: Undefined references to __udivsi3 and __umodsi3 (arm-elf)

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Peter Tiang wrote:
> 
> Thanks for the clarification, guys.
> 
> Next issue when libgcc.a is linked is
> undefined reference to `atexit' in function
> `__do_global_ctors'

I find that for simplicity you often want to use 

--start-group LIBS --end-group 

so that ld will make multiple passes across the library
set.  Remember that ld only pulls out the objects it
needs to satisfy the requirements at the moment.  So
you are linking against libc.a before libgcc.a and 
the need for atexit() is introduced after ld is
finished looking at libc.a.

Alternatively you could try to find the one 
path through the libraries and link against them
in that order.  You might have to list libc.a twice.
It is easier to use the group concept.

> I believe this is from calls to __gccmain
> made from main().
> 
> Is there a FAQ somewhere as this seems to
> be quite common issues.

As a general rule, when you abandon letting gcc 
invoke the linker and use ld directly, you are
exposing yourself to all sorts of ugliness.  
This is why for the RTEMS community, we abandoned
linking with ld and use gcc.

> Rgds,
> Peter
> 
> > Yes.  The libgcc library contains C operations such as divide, mod,
> multiply...
> > (you are missing a divide and mod operator below).  Such operations
> require
> > target-specific code and sometimes are too big/complex to generate in-line
> so the compiler
> > creates functions for them and generates calls whenever C code (including
> newlib) uses them.
> > They do not belong in the C library as they are part of supporting the
> > C language for the platform.
> >
> > -- Jeff J.
> >

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985