12

I am having a strange problem.

The math libraries has been added to my makefile.

# Include standard C library LDFLAGS += -lc # Include standard math library LDFLAGS += -lm

And in the output file (.map), I can see that everything has been linked properly:

LOAD c:/gnu/powerpc-eabi/3pp.ronetix.powerpc-eabi/bin/../lib/gcc/powerpc-eabi/4.3.3/nof\libgcc.a LOAD c:/gnu/powerpc-eabi/3pp.ronetix.powerpc-eabi/bin/../lib/gcc/powerpc-eabi/4.3.3/../../../../powerpc-eabi/lib/nof\libc.a LOAD c:/gnu/powerpc-eabi/3pp.ronetix.powerpc-eabi/bin/../lib/gcc/powerpc-eabi/4.3.3/../../../../powerpc-eabi/lib/nof\libm.a

when I do

z = pow((double) 2, (double) 3);

it works fine. But if I test another function, like:

double result = asin(x);

I’ll get:

undefined reference to `asin' collect2: ld returned 1 exit status

How can this be? Both pow and asin are available in math.h. See below:

/* Nonreentrant ANSI C functions */ #ifndef _REENT_ONLY #ifndef __math_6881 extern double acos _PARAMS((double)); extern double asin _PARAMS((double)); extern double atan2 _PARAMS((double, double)); extern double cosh _PARAMS((double)); extern double sinh _PARAMS((double)); extern double exp _PARAMS((double)); extern double ldexp _PARAMS((double, int)); extern double log _PARAMS((double)); extern double log10 _PARAMS((double)); extern double pow _PARAMS((double, double)); extern double sqrt _PARAMS((double)); extern double fmod _PARAMS((double, double)); #endif /* ! defined (__math_68881) */ #endif /* ! defined (_REENT_ONLY) */

How can one work and the other one generate linker issue?

If I run -nm on libm.a, I’ll get the following result (sorry for the huge output; I have only copied the sections with the word sin):

lib_a-e_asin.o: U __adddf3 U __divdf3 U __gtdf2 00000000 T __ieee754_asin U __ieee754_sqrt U __muldf3 U __subdf3 U fabs lib_a-e_j0.o: U __adddf3 U __divdf3 U __gtdf2 00000470 T __ieee754_j0 U __ieee754_log U __ieee754_sqrt 000009b8 T __ieee754_y0 U __ltdf2 U __muldf3 U __subdf3 U cos U fabs 000000b0 r pR2 00000108 r pR3 00000058 r pR5 00000000 r pR8 000000e0 r pS2 00000138 r pS3 00000088 r pS5 00000030 r pS8 00000004 t pzero 00000220 r qR2 00000280 r qR3 000001c0 r qR5 00000160 r qR8 00000250 r qS2 000002b0 r qS3 000001f0 r qS5 00000190 r qS8 00000218 t qzero U sin lib_a-e_j1.o: U __adddf3 U __divdf3 U __gtdf2 00000470 T __ieee754_j1 U __ieee754_log U __ieee754_sqrt 00000950 T __ieee754_y1 U __muldf3 U __subdf3 U cos U fabs 00000004 t pone 000000b0 r pr2 00000108 r pr3 00000058 r pr5 00000000 r pr8 000000e0 r ps2 00000138 r ps3 00000088 r ps5 00000030 r ps8 00000218 t qone 00000220 r qr2 00000280 r qr3 000001c0 r qr5 00000160 r qr8 00000250 r qs2 000002b0 r qs3 000001f0 r qs5 00000190 r qs8 U sin lib_a-e_jn.o: U __adddf3 U __divdf3 U __floatsidf U __gedf2 U __gtdf2 U __ieee754_j0 U __ieee754_j1 00000434 T __ieee754_jn U __ieee754_log U __ieee754_sqrt U __ieee754_y0 U __ieee754_y1 00000000 T __ieee754_yn U __ltdf2 U __muldf3 U __subdf3 U cos U fabs U sin lib_a-e_sinh.o: U __adddf3 U __divdf3 U __gtdf2 U __ieee754_exp 00000000 T __ieee754_sinh U __muldf3 U __subdf3 U expm1 U fabs lib_a-ef_asin.o: U __addsf3 U __divsf3 U __gtsf2 00000000 T __ieee754_asinf U __ieee754_sqrtf U __mulsf3 U __subsf3 U fabsf lib_a-ef_j0.o: U __addsf3 U __divsf3 U __gtsf2 0000035c T __ieee754_j0f U __ieee754_logf U __ieee754_sqrtf 000006cc T __ieee754_y0f U __ltsf2 U __mulsf3 U __subsf3 U cosf U fabsf 00000058 r pR2 00000084 r pR3 0000002c r pR5 00000000 r pR8 00000070 r pS2 0000009c r pS3 00000044 r pS5 00000018 r pS8 00000004 t pzerof 00000110 r qR2 00000140 r qR3 000000e0 r qR5 000000b0 r qR8 00000128 r qS2 00000158 r qS3 000000f8 r qS5 000000c8 r qS8 000001a0 t qzerof U sinf lib_a-ef_j1.o: U __addsf3 U __divsf3 U __gtsf2 0000031c T __ieee754_j1f U __ieee754_logf U __ieee754_sqrtf 0000062c T __ieee754_y1f U __mulsf3 U __subsf3 U cosf U fabsf 00000004 t ponef 00000058 r pr2 00000084 r pr3 0000002c r pr5 00000000 r pr8 00000070 r ps2 0000009c r ps3 00000044 r ps5 00000018 r ps8 000001a0 t qonef 000000b0 r qr2 000000e0 r qr8 000000c8 r qs2 000000f8 r qs8 U sinf lib_a-ef_sinh.o: U __addsf3 U __divsf3 U __gtsf2 U __ieee754_expf 00000000 T __ieee754_sinhf U __mulsf3 U __subsf3 U expm1f U fabsf lib_a-er_lgamma.o: U __adddf3 U __divdf3 U __eqdf2 U __fixdfsi U __floatsidf 00000004 T __ieee754_lgamma_r U __ieee754_log U __kernel_cos U __kernel_sin U __ltdf2 U __muldf3 U __nedf2 U __subdf3 U fabs U floor lib_a-erf_lgamma.o: U __addsf3 U __divsf3 U __eqsf2 U __fixsfsi U __floatsisf 00000004 T __ieee754_lgammaf_r U __ieee754_logf U __kernel_cosf U __kernel_sinf U __ltsf2 U __mulsf3 U __nesf2 U __subsf3 U fabsf U floorf lib_a-k_sin.o: U __adddf3 U __fixdfsi 00000000 T __kernel_sin U __muldf3 U __subdf3 lib_a-kf_sin.o: U __addsf3 U __fixsfsi 00000000 T __kernel_sinf U __mulsf3 U __subsf3 lib_a-s_asinh.o: U __adddf3 U __divdf3 U __gtdf2 U __ieee754_log U __ieee754_sqrt U __muldf3 00000000 T asinh U fabs U log1p lib_a-s_cos.o: U __ieee754_rem_pio2 U __kernel_cos U __kernel_sin U __subdf3 00000000 T cos lib_a-s_isinf.o: 00000000 T isinf lib_a-s_isinfd.o: 00000000 T __isinfd lib_a-s_sin.o: U __ieee754_rem_pio2 U __kernel_cos U __kernel_sin U __subdf3 00000000 T sin lib_a-sf_asinh.o: U __addsf3 U __divsf3 U __gtsf2 U __ieee754_logf U __ieee754_sqrtf U __mulsf3 00000000 T asinhf U fabsf U log1pf lib_a-sf_cos.o: U __ieee754_rem_pio2f U __kernel_cosf U __kernel_sinf U __subsf3 00000000 T cosf lib_a-sf_isinf.o: 00000000 T isinff lib_a-sf_isinff.o: 00000000 T __isinff lib_a-sf_sin.o: U __ieee754_rem_pio2f U __kernel_cosf U __kernel_sinf U __subsf3 00000000 T sinf lib_a-w_asin.o: U __errno U __fdlib_version U __gtdf2 U __ieee754_asin U __isnand 00000004 T asin U fabs U matherr U nan lib_a-w_sincos.o: U cos U sin 00000000 T sincos lib_a-w_sinh.o: U __errno U __fdlib_version U __gtdf2 U __ieee754_sinh U finite U matherr 00000004 T sinh lib_a-wf_asin.o: U __errno U __extendsfdf2 U __fdlib_version U __gtsf2 U __ieee754_asinf U __truncdfsf2 00000004 T asinf U fabsf U isnanf U matherr U nan lib_a-wf_sincos.o: U cosf 00000000 T sincosf U sinf lib_a-wf_sinh.o: U __errno U __extendsfdf2 U __fdlib_version U __gtsf2 U __ieee754_sinhf U __truncdfsf2 U finitef U matherr 00000004 T sinhf

I tested some more, and the problem is as follows (not what I originally stated above):

double aa; double bb = 1.0; double cc; aa = sin(1.0); cc = sin (bb);

When I try to build, I get a 'undefined reference' at the last line, meaning that when I use constants it is fine, but when I pass variables to the sin functions it will not link. I also tested many of the other math functions, and I’ll get the exact same linker issue. As soon as I pass a variable to a math function, I can not link any more. Any ideas?

Improve this question
14
  • 2
    If you use your platform's tool to list the symbol table for an object file (e.g. nm ), are the missing functions listed in libm.a? The error indicates the problem is in the link phase, at which point the header files are no longer involved. In other words, the contents of math.h won't affect the issue. Commented Jun 30, 2011 at 11:49
  • 1
    Check your LD_LIBRARY_PATH. You might be looking at a different library to the one the linker is using. Remember that the header file math.h might also refer to a different library to the one being picked up. Commented Jun 30, 2011 at 13:09
  • 2
    Can you reproduce the problem with just one source file, building the executable without any makefiles, like so: gcc -o test test.c -lm or perhaps gcc -static -o test test.c -lm? Commented Jun 30, 2011 at 13:59
  • 1
    @hexa: That would change the behaviour of the compiler, not the content of the library. Dialect selection may remove parts of the header file, but that would cause a compiler not a linker error. Commented Jun 30, 2011 at 21:56
  • 3
    If you are compiling optimized the compiler can optimize away the run-time call to sin(1.0), replacing it by a constant computed at compile time. Have you #included <math.h> (see Jonathan's answer)? Commented Jul 1, 2011 at 16:08

4 Answers 4

Reset to default
12

The linker isn't complaining about pow((double) 2, (double) 3) because the compiler is replacing it with a constant 8.0. You shouldn't depend on this behavior; instead, you should always use the -lm option properly. (BTW, that's more clearly written as pow(2.0, 3.0).

Consider the following program:

#include <stdio.h> #include <math.h> int main(void) { double x = 0.1; printf("%g\n", pow(2.0, 3.0)); printf("%g\n", asin(x)); return 0; }

When I compile and link it on my system using

gcc c.c -o c

I get:

/tmp/ccXx8ZRL.o: In function `main': c.c:(.text+0x36): undefined reference to `asin' collect2: ld returned 1 exit status

Note that it complains about asin, but not about pow.

If I change the pow call to pow(x, 3.0), I get:

/tmp/ccOeSaBK.o: In function `main': c.c:(.text+0x24): undefined reference to `pow' c.c:(.text+0x52): undefined reference to `asin' collect2: ld returned 1 exit status

Normally if you want to call a standard math library function, you need to have #include <math.h> at the top of the source file (I presume you already have that) and you need to pass the -lm option to the compiler after the file that needs it. (The linker keeps track of references that haven't been resolved yet, so it needs to see the object file that refers to asin first, so it can resolve it when it sees the math library.)

The linker isn't complaining about the call to pow(2.0, 3.0) because gcc is clever enough to resolve it to a constant 8.0. There's no call to the pow function in the compiled object file, so the linker doesn't need to resolve it. If I change pow(2.0, 3.0) to pow(x, 3.0), the compiler doesn't know what the result is going to be, so it generates the call.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

10

The sequence for -lm -lc -lgcc plays a very important role. Only this sequence works for me.

These commands go to the Linker Options!

Improve this answer

1 Comment

The -lc and lgcc options are not normally necessary. What environment requires them?
8

Are you including <math.h> everywhere?

Notice that the names in the library are prefixed with __ieee754_, but the ones the linker can't find are not.

What happens when you compile this code?

#include <math.h> int main(void) { double d = pow(2, 3); double e = asin(1.0 / d); return (int)(e+1); }

If the file is mathtest.c, then compile with:

gcc -o mathtest mathtest.c -lm

(Given that this fails to compile, what symbols are defined in mathtest.o?)

I added a comment to the main question:

Which platform are you on? Which C compiler are you using? Are you cross-compiling? What is the command line that is executed to do the linking? (I see DOS/Windows C: paths and PowerPC architecture.) Is there any chance you are using <tgmath.h> for type-generic math?

Looking at the LOAD paths you give, I see:

LOAD c:/gnu/powerpc-eabi/3pp.ronetix.powerpc-eabi/bin/../lib/gcc/powerpc-eabi/4.3.3/../../../../powerpc-eabi/lib/nof\libm.a

Which can, I think, be simplified to:

LOAD c:/gnu/powerpc-eabi/3pp.ronetix.powerpc-eabi/powerpc-eabi/lib/nof\libm.a

One part of that path that intrigues me is the nof part; could that be 'no floating point'? The other part that really intrigues me is the presence of powerpc with the c: prefix; it smacks of cross-compilation for PowerPC on a Windows platform. It is important to be forthright and explicit about such things; we need that sort of information to be able to help you sensibly.

Was this the libm.a library that you tested, or did you experiment with another file?

Improve this answer

8 Comments

"Undefined reference" is a linker error, not a compiler error, failing to include a header file would cause a compler error (or a warning in C89).
@Clifford: unless including the header mapped the source code name from asin to __ieee574_asin. The output from nm shows a symbol __ieee574_asin, and if the header mapped the name as suggested, then calling the function without the header would mean that the 'wrong' function was called. If the sample code that I supplied links but the original poster's code does not, I'd be inclined to regard that as 'case proven'. Yes, you can legitimately argue that you are supposed to be able to write extern double asin(double); and it should work, but I've seen this sort of name mapping before.
ISO/IEC 9899:1999 (E) §7.1.4/2: Provided that a library function can be declared without reference to any type defined in a header, it is also permissible to declare the function and use it without including its associated header. So if the include is required, the implementation is non-conforming.
@bdonlan: I never said otherwise - and I'm aware of that bit of the standard. But I've seen this sort of game played on (Linux) implementations before. And that is one (major) reason why it is better to include the system header than to second guess the system. But I think that if my example does not compile cleanly, then the implementation is simply broken. If it does compile cleanly but the OP's code does not, then the OP's code does something tantamount to not including <math.h> where this implementation requires it...and the fix of including <math.h> will work everywhere.
@Jonathan, you have written (almost) the same code as I had originally, and you are linking with -lm as I have. I don´t see any diffrence. I got the undefined reference to ´asin´ again.
|
1

You can use "filename.c -lm" to solve this problem. And please don't forget to use header file math.h.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.