0
\$\begingroup\$

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)

\$\endgroup\$
3
  • \$\begingroup\$ Oh and i'm on a x86 Mac with the latest tools installed using Fink. \$\endgroup\$
    – Jan de Jager
    Commented Mar 30, 2011 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
    Commented Mar 30, 2011 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
    Commented Mar 30, 2011 at 16:33

1 Answer 1

Reset to default
1
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\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
    Commented Apr 12, 2011 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
    Commented Apr 14, 2011 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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