So this seems to be a generic issue. "libc.a" is associate with some sort of incompatibility with floating point math and/or the correct library used.

I've added the "-lm" as suggested on the forums, but still unable to link/compile correctly?

Any other suggestions?

/opt/local/lib/gcc/avr/4.0.2/../../../../avr/lib/avr5/libc.a(cmpsf2.o):../../../libm/fplib/cmpsf2.S:58: multiple definition of __ltsf2' /opt/local/lib/gcc/avr/4.0.2/avr5/libgcc.a(_lt_sf.o):/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_avr-gcc/work/build/gcc/fp-bit.c:1272: first defined here /opt/local/lib/gcc/avr/4.0.2/../../../../avr/lib/avr5/libc.a(floatsisf.o):../../../libm/fplib/floatsisf.S:44: multiple definition of__floatsisf' /opt/local/lib/gcc/avr/4.0.2/avr5/libgcc.a(_si_to_sf.o):/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_avr-gcc/work/build/gcc/fp-bit.c:1334: first defined here /opt/local/lib/gcc/avr/4.0.2/../../../../avr/lib/avr5/libc.a(modf.o):../../../libm/fplib/modf.S:88: relocation truncated to fit: R_AVR_13_PCREL against symbol `__subsf3' defined in .text section in /opt/local/lib/gcc/avr/4.0.2/avr5/libgcc.a(_addsub_sf.o)

  • \$\begingroup\$ Oh and i'm on a x86 Mac with the latest tools installed using Fink. \$\endgroup\$ – Jan de Jager Mar 30 '11 at 14:42
  • 1
    \$\begingroup\$ AAAHHH!!! sorted it out... "-lm" should be the last item passed to the linker... !! WTF, been struggling with this for the last 4 days... \$\endgroup\$ – Jan de Jager Mar 30 '11 at 14:49
  • 1
    \$\begingroup\$ Go ahead and do us a favor. Either close your question, or better yet make an answer that explains what was wrong and then select your own answer. \$\endgroup\$ – Kellenjb Mar 30 '11 at 16:33

A little explanation of what's really going on:

The -l argument order does not normally matter on computers since most libraries are dynamically loaded (.dll, .dylib or .so) and are truly linked only at program startup time.

OTOH on the AVR all libraries are static. When linking with static libraries the linker adds to the program only the functions he currently needs from the library. If you pass -lm on the command line before a file that needs a particular function you will get unresolved symbols errors.

| improve this answer | |
  • \$\begingroup\$ Curiously this does not explain the error messages above, as they show a multiple definition, not an undefined symbol. Also, for mutual dependencies, sometimes adding the same library more than once can help. \$\endgroup\$ – Yann Vernier Apr 12 '11 at 12:06
  • \$\begingroup\$ @Yann Right. I was trying to explain why passing the -lm last fixed the problem and I failed to notice what the error messages really were. The OP could add some minimal code that triggers the error but I do not think he cares anymore – he already fixed his problem after all. \$\endgroup\$ – jpc Apr 14 '11 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.