This is the mail archive of the newlib@sourceware.org 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: Building newlib without -mhard-float


On 07 September 2007 01:27, Rick Mann wrote:

>> Here's another odd thing I'm seeing. With my current build of the
>> tools & multilib (using --target=arm-elf and --with-cpu=xscale), if
>> I write single- and double-precision floating point code like this:

>> The compiler generates calls to __muldf3() and the like and
>> everything links and executes fine.

>> But, if I call sprintf(), the linker complains about routines like
>> __muldf3 (and many others) not being found:

>> /usr/local/arm3/lib/gcc/arm-elf/4.2.1/../../../../arm-elf/lib/libc.a
>> (lib_a-dtoa.o): In function `_dtoa_r':
>> /Users/rmann/Desktop/gcc2/newlib-1.15.0/build/arm-elf/newlib/libc/
>> stdlib/../../../../../newlib/libc/stdlib/dtoa.c:463: undefined reference
>> to `__muldf3' 
>> 
>> Even more interesting, if I leave in my own floating-point code,
>> that reference in _dtoa_r to __muldf3 is linked fine. If I remove
>> my own floating-point code, the error comes back. It seems that GCC
>> is unable to link the floating-point math calls in libc.a on its
>> own, but me making reference to them in my main() makes it okay.
> 
> Well, I feel kinda dumb. I moved the -lgcc to the end of my list, and
> it links okay now

> I'm also not sure why putting -lgcc last makes a difference, but I
> guess I remember reading something about bidirectional references
> requiring the libraries to be listed multiple times.

  Linking is strictly in command line order.  As it runs along the commandline
it picks up undefined references; when it finds a new library or file it
resolves any outstanding references *but* it doesn't memorize all the syms
from that file and re-use them to fill in undefined references that turn up
*later* on the command-line.  See also the --start-group and --end-group
options to ld.

  However, the real underlying cause of the problem is that you're doing it
wrong.  Don't invoke ld directly.  Use the gcc compiler driver, and it will
automatically get all the startup files and libraries in the right places for
you.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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