tan(x) function doesn't work in linux C
 

The "tan()" fucntion in linux doesn't work on my machine. It gives some error along with some message like "ld status 1" (I am right now on the windows machine so can't tell you the exact error).
The problem persists for all the <math.h> functions like"pow(),sin(),cos() atan()" etc.

How can I use the <math.h> header file so that the tan() and other functions will work?.

Did you compile as

humm....
 

nope... should i?? wii try...

thanx it works!
 

hey thanx that works well but plz tell me why use "gcc" along with "-lm"

"-lm" means "link the standard C math library, 'libm.so', into my executable"

Some more thoughts on this....
 

Thanks for the answers, it fixed my problem with sin(x) also. But I am wondering if this is correct behaviour. After all, in the program there is an #include <math.h> directive, which I think should cause the correct libraries to be loaded. I suppose that the linker knows nothing about compiler directives. But I do wonder if that is really correct, or should it be fixed?:scratch:

The include tells the compiler to use a certain include file. This file contains function prototypes, definitions etc. So the compiler e.g can check if you use the correct syntax for a function.

It does not include the actual functions that you want to use. These are placed in labraries and you (sometimes) have to include the specific library during the linking.

Actually, you always need to tell which libraries your program use, except for the standard c library ([g]libc), which is always linked by default.

OK, I understand that, and how to get round it, and thanks to all who have answered both the original poster and myself. It saved me possibly many hours.

But, it still seems to me that there is a duplication of input required by declaring the library with an #include directive in the source code (which I would definitely expect to do), and also invoking it on the command line. I would have thought that the #include alone "should" be sufficient, which is what I was questioning. After all, what is an #include for?

Now there may well be a very good and fundamental reason for all of this, if so it would be very interesting to know. Otherwise, I would suggest that just maybe a very minor enhancement to the way things work, if it is possible, might please a lot of people, myself included.

The header files defines the prototype of the function(s) that you wish to access.

The libraries consist of the actual binary code that will be executed when the program runs.

These are different files, living in different file locations. There may even be different versions of the library on the same machine (for example versions optimised for speed of execution or for size of executable, or a really new bells and whistles version rather than the staid but stable version)

So which one to link in? That is where the switch comes in to tell the linker please link in this version of the library.

Not to mention plenty of different include files can refer to a single library, or a combination of libraries, and you only need to include the ones necessary.

On the other hand, you can have "libraryless" include files, defining useful things for your program, but that are not backed at all by a library.

In summary, there is absolutely no one to one relationship between include files and libraries.

Thank you both for the explanations, which do indeed make sense now.

I must say that support via this site is commendably fast, far better than anything I have ever seen in the proprietary world!

Dang did I forget to copyright my comments... :mad: