«

Hi,

I am compiling a C source file that includes math.h but I get an error
message that states undefined reference to floor().

How could that happen if this function is in math.h, isn't in the
standard library? Do I need to link it explicitly?

Thanks,

Michael

Michael McGarry wrote:
> Hi,
>
> I am compiling a C source file that includes math.h but I get an error
> message that states undefined reference to floor().
>
> How could that happen if this function is in math.h, isn't in the
> standard library? Do I need to link it explicitly?
>

On Solaris and Linux the math functions are in a different library that
the
compiler does not link against unless you tell it to. It's called
libm.so (-lm).


--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

"Michael McGarry" <> writes:
> I am compiling a C source file that includes math.h but I get an error
> message that states undefined reference to floor().
>
> How could that happen if this function is in math.h, isn't in the
> standard library? Do I need to link it explicitly?

<http://www.c-faq.com/fp/libm.html>

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

That worked (i.e., -lm). Thanks!!!

Keith Thompson wrote:
> "Michael McGarry" <> writes:
> > I am compiling a C source file that includes math.h but I get an error
> > message that states undefined reference to floor().
> >
> > How could that happen if this function is in math.h, isn't in the
> > standard library? Do I need to link it explicitly?
>
> <http://www.c-faq.com/fp/libm.html>

Do you know the history of the bug?

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

"Nelu" <> writes:
> Keith Thompson wrote:
>> "Michael McGarry" <> writes:
>> > I am compiling a C source file that includes math.h but I get an error
>> > message that states undefined reference to floor().
>> >
>> > How could that happen if this function is in math.h, isn't in the
>> > standard library? Do I need to link it explicitly?
>>
>> <http://www.c-faq.com/fp/libm.html>
>
> Do you know the history of the bug?

It's arguable whether it's actually a bug.

The math library is fairly large, and a lot of C program don't use it
(there's seldom much need for floating-point math in system code).
Back when systems were smaller and linkers were dumber, there was a
significant advantage in not including the math code in the standard
library; it made a lot of programs substantially smaller.

These days, size is less of an issue (but still not insignificant),
and linkers *should* be able to load only the functions that are
actually called. (I'm actually not sure of the current state of the
art in linkers, and the existence of dynamic libraries probably
confuses things further.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Michael McGarry wrote:
> Hi,
>
> I am compiling a C source file that includes math.h but I get an error
> message that states undefined reference to floor().
>
> How could that happen if this function is in math.h, isn't in the
> standard library? Do I need to link it explicitly?

Learn to check the FAW before posting. Sometimes you need to be a tiny
bit creative to decide which question is appropriate. In your case, it is
<http://c-faq.com/fp/libm.html> "I'm trying to do some simple trig, and
I am #including <math.h>, but the linker keeps complaining that
functions like sin and cos are undefined."

[My spelling corrected]
Michael McGarry wrote:
> Hi,
>
> I am compiling a C source file that includes math.h but I get an error
> message that states undefined reference to floor().
>
> How could that happen if this function is in math.h, isn't in the
> standard library? Do I need to link it explicitly?

Learn to check the FAQ before posting. Sometimes you need to be a tiny
bit creative to decide which question is appropriate. In your case, it is
<http://c-faq.com/fp/libm.html> "I'm trying to do some simple trig, and
I am #including <math.h>, but the linker keeps complaining that
functions like sin and cos are undefined."

On Thu, 16 Feb 2006 00:25:21 GMT, Martin Ambuhl
<> wrote in comp.lang.c:

> Michael McGarry wrote:
> > Hi,
> >
> > I am compiling a C source file that includes math.h but I get an error
> > message that states undefined reference to floor().
> >
> > How could that happen if this function is in math.h, isn't in the
> > standard library? Do I need to link it explicitly?
>
> Learn to check the FAW before posting.

....but if you can't find the FAW, at least check the FAQ.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

>> Keith Thompson wrote:
>>> <http://www.c-faq.com/fp/libm.html>

>"Nelu" <> writes:
>> Do you know the history of the bug?

In article <>
Keith Thompson <kst-> wrote:
>It's arguable whether it's actually a bug.

Indeed.

>The math library is fairly large, and a lot of C program don't use it
>(there's seldom much need for floating-point math in system code).
>Back when systems were smaller and linkers were dumber, there was a
>significant advantage in not including the math code in the standard
>library; it made a lot of programs substantially smaller.

Although even by the mid-1980s this was not much of a reason.

>These days, size is less of an issue (but still not insignificant),
>and linkers *should* be able to load only the functions that are
>actually called. (I'm actually not sure of the current state of the
>art in linkers, and the existence of dynamic libraries probably
>confuses things further.)

Dynamic libraries do make things different.

One of the important ways they make things different is that they
offer the opportunity to optimize the system at boot time.

Suppose, for instance, that you have a Celeron, or an Athlon, or
a Pentium4, or a PentiumPRO, or an x86-64, or any of the myriad
other implementations that everyone uses since nobody ever uses an
architecture other than the x86. There are ways to implement
the math functions so that they will work on every one of these
machines -- but no matter which way(s) you pick, they will be
unnecessarily slow on *some* of them, but very fast on some other(s).

Ideally, what you would like to have is a system in which the
math routines are chosen based on the CPU.

The CPU is, of course, fixed at boot time (you must power down the
machine to replace it). So, why not build 37 (or however many it
takes) *different* math libraries, each one optimal for one particular
implementation, and have the boot process choose the correct one?

To do this, of course, we have to have some code at boot time that
picks out the right library. This code will not do any math itself,
but -- if we write it in C -- will need the *rest* of the C library
(or some substantial portion thereof). So this works best if the
math library is a separate library, that can be installed during the
boot process by a program that uses the C library but not the math
library.

The actual benefit is pretty small on the x86 family, but can be
enormous on those other architectures that no one ever uses. In
particular, systems where floating-point hardware is optional will
often want to have a "software-only" math library and a "hardware-
based" math library.

(As it happens, various *other* functions, including those one would
want in the library used by the boot-time library-selection program,
are included in the set one might want to have swapped about. So
this can work even better if one can arrange to have multiple versions
of the entire C runtime libraries, math or not; but separating out
the libm section is easier and gets most of the performance in some
important cases.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.