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

pranavojha 03-03-2006 09:08 AM

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

Berhanie 03-03-2006 09:21 AM

Did you compile as

gcc -lm program_name.c

pranavojha 03-03-2006 09:22 AM


Originally Posted by Berhanie
Did you compile as

gcc -lm program_name.c

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

pranavojha 03-03-2006 11:17 PM

thanx it works!

Originally Posted by Berhanie
Did you compile as

gcc -lm program_name.c

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

paulsm4 03-03-2006 11:33 PM

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

tiger9999tiger 03-10-2006 06:40 AM

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:

Wim Sturkenboom 03-10-2006 07:04 AM

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.

jlliagre 03-10-2006 07:11 AM

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.

tiger9999tiger 03-20-2006 10:52 AM

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.

graemef 03-20-2006 11:17 AM

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.

jlliagre 03-20-2006 11:57 AM

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.

tiger9999tiger 03-21-2006 03:28 AM

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!

graemef 03-21-2006 07:56 AM


Originally Posted by tiger9999tiger
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:

All times are GMT -5. The time now is 05:48 PM.