undefined reference to “only some math.h” functions

Question

I am having a strange problem.

The math libraries has been added to my makefile.

# include standard C library
LDFLAGS += -lc
# include standard math          


        

Answer 1

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.

Answer 2

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

Answer 3

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

These commands go to the Linker Options!

Answer 4

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 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?