ceil() and log10() - undefined?

[ptn]

Hi everyone,

I was messing around with math.h and I got this error:

"""
/tmp/ccefZYYN.o: In function `digcount':
itos.c.text+0x103): undefined reference to `log10'
itos.c.text+0x111): undefined reference to `ceil'
collect2: ld returned 1 exit status

shell returned 1
"""

It can't be that log10() and ceil() aren't defined, because math.h
takes care of that. I admit that I have no idea what .text+0x111/.text
+0x103 means

The complete code is here:

# include <stdio.h>
# include <malloc.h>
# include <math.h>

int digcount(int num); // counts the digits of <num>

main()
// transform a number to a string
{
int num, fact, dig, digits, i;
char *s;

scanf("%d", &num);
digits = digcount(num);
s = (char *) malloc((digits + 1) * sizeof(char)); // assign just
enough space
s += (digits - 1); // go to the last address of the memory space
assigned
*s-- = '\0'; // mark the end of the string
for (i = 0; i < digits; i++) {
dig = num % 10;
num /= 10;
*s-- = '0' + dig; // store digit by digit
}
printf("\"%s\"\n", ++s); // after the for, s is pointing to the
addres before the start of the string
}

int digcount(int num)
/* N = trunc(log(x), 0) + 1, where N is the number of digits of x */
{
double ans;

ans = log10(num);
ans = ceil(ans);
return (int) ans;
}

Any ideas are welcome.
(I'm using Vim + gcc under Ubuntu Feisty Fawn)

Thanks,

Pablo Torres Navarrete

 

[Peter Nilsson]

/tmp/ccefZYYN.o: In function `digcount':
itos.c.text+0x103): undefined reference to `log10'
itos.c.text+0x111): undefined reference to `ceil'
collect2: ld returned 1 exit status

It can't be that log10() and ceil() aren't defined, because
math.h takes care of that.

For the compiler perhaps, but not for the linker.

See the FAQ: http://c-faq.com/fp/libm.html

 

[Ben Pfaff]

I was messing around with math.h and I got this error:

"""
/tmp/ccefZYYN.o: In function `digcount':
itos.c.text+0x103): undefined reference to `log10'
itos.c.text+0x111): undefined reference to `ceil'
collect2: ld returned 1 exit status

shell returned 1
"""

This is in the C FAQ.

14.3: I'm trying to do some simple trig, and I am #including <math.h>,
but I keep getting "undefined: sin" compilation errors.

A: Make sure you're actually linking with the math library. For
instance, under Unix, you usually need to use the -lm option, at
the *end* of the command line, when compiling/linking. See also
questions 13.25, 13.26, and 14.2.

 

[ptn]

This is in the C FAQ.

14.3: I'm trying to do some simple trig, and I am #including <math.h>,
but I keep getting "undefined: sin" compilation errors.

A: Make sure you're actually linking with the math library. For
instance, under Unix, you usually need to use the -lm option, at
the *end* of the command line, when compiling/linking. See also
questions 13.25, 13.26, and 14.2.

Thank you very much. Program runs OK now

ptn

 

[Martin Ambuhl]

Hi everyone,

I was messing around with math.h and I got this error:

"""
/tmp/ccefZYYN.o: In function `digcount':
itos.c.text+0x103): undefined reference to `log10'
itos.c.text+0x111): undefined reference to `ceil'
collect2: ld returned 1 exit status

shell returned 1
"""

It can't be that log10() and ceil() aren't defined, because math.h
takes care of that.

No, it doesn't.
You want to get the FAQ <http://c-faq.com/index.html> and check it
before posting any more questions. Most beginner's questions have been
asked many times before and answered many times before. If you check
the FAQ before posting, you will avoid the ire of people who get very
tired of this. In your case, you have asked a form of the question
found, along with the answer, at <http://c-faq.com/fp/libm.html>,
"Question 14.3, Q: 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."

BTW, not all of us agree with the word "bug" given in the answer.

 

[Martin Ambuhl]

ptn wrote:
[...]

# include <malloc.h>

I forgot to mention that there is no such standard header. Include
<stdlib.h> for malloc() and friends.

 

[CBFalconer]

.... snip ...

The complete code is here:

# include <stdio.h>
# include <malloc.h>

No such standard include file exists. Probably should be stdlib.h.

# include <math.h>

int digcount(int num); // counts the digits of <num>

main()

Main returns an int. Say so. Use "int main(void)".

// transform a number to a string

C89 does not allow // comments, nor does Usenet, because of line
wrapping. Use /* ... */

{
int num, fact, dig, digits, i;
char *s;

scanf("%d", &num);

NEVER use scanf without checking its error return. This should be
"if (1 != scanf("5d", & num)) /* recover */ else /* OK */

digits = digcount(num);
s = (char *) malloc((digits + 1) * sizeof(char)); // assign just

Never cast the return from malloc. sizeof(char) is one.

enough space

This is a syntax error!!

s += (digits - 1); // go to the last address of the memory space
assigned

So is this !!

*s-- = '\0'; // mark the end of the string
for (i = 0; i < digits; i++) {
dig = num % 10;
num /= 10;
*s-- = '0' + dig; // store digit by digit
}
printf("\"%s\"\n", ++s); // after the for, s is pointing to the
addres before the start of the string

Another syntax error here. Then you have failed to return 0,
EXIT_FAILURE, or EXIT_SUCCESS from main. The EXITs are found in
stdlib.h.

}

int digcount(int num)
/* N = trunc(log(x), 0) + 1, where N is the number of digits of x */
{
double ans;

ans = log10(num);
ans = ceil(ans);
return (int) ans;

This is a useless cast. Just eliminate it. In fact you can use:

return ceil(log10(num));

and the default conversions will handle everything. All casts are
suspicious and probably erroneous and/or unneeded, except for
variadic function parameters.

}

Any ideas are welcome.

I suggest you first fix the above errors/oversights, and limit the
line length to 72 chars. The best way to handle malloc's is:

if (!(p = malloc(N * sizeof *p))) /* recovery code */;
else /* successful malloc, carry on */

 

[ptn]

}

I suggest you first fix the above errors/oversights, and limit the
line length to 72 chars. The best way to handle malloc's is:

if (!(p = malloc(N * sizeof *p))) /* recovery code */;
else /* successful malloc, carry on */

You have given me a lot more information than what I'd expected. I
learned a lot

ptn

 

[santosh]

ptn wrote:

[CBFalconer wrote the text below]

You have given me a lot more information than what I'd expected. I
learned a lot

Please don't snip attributions, i.e., those lines beginning with "so-and-so
wrote:"

Removing them makes the discussion hard to follow for those without threaded
newsreaders.

 

[Richard Heathfield]

santosh said:

ptn wrote:

[CBFalconer wrote the text below]

....but Chuck didn't write that bit.

Please don't snip attributions, i.e., those lines beginning with
"so-and-so wrote:"

Removing them makes the discussion hard to follow for those without
threaded newsreaders.

Even so, ptn should be applauded for paying attention to Chuck's points
even though they were not directly related to the question he actually
asked. Someone has actually taken the trouble to learn more about C in
general, rather than "enough to get me over *this* hill". I wish there
were more like ptn.

 

[Richard]

ptn wrote:

[CBFalconer wrote the text below]

You have given me a lot more information than what I'd expected. I
learned a lot

Please don't snip attributions, i.e., those lines beginning with "so-and-so
wrote:"

Removing them makes the discussion hard to follow for those without threaded
newsreaders.

KNode is a threaded news reader, so why the noise?

 

[santosh]

ptn wrote:

[CBFalconer wrote the text below]

Any ideas are welcome.

I suggest you first fix the above errors/oversights, and limit the
line length to 72 chars. The best way to handle malloc's is:

if (!(p = malloc(N * sizeof *p))) /* recovery code */;
else /* successful malloc, carry on */

You have given me a lot more information than what I'd expected. I
learned a lot

Please don't snip attributions, i.e., those lines beginning with
"so-and-so wrote:"

Removing them makes the discussion hard to follow for those without
threaded newsreaders.

KNode is a threaded news reader, so why the noise?

I have it in a mode which shows only unread articles, so that I needn't sort
through hundreds of previously read ones. This also avoids the problem of
articles in long threads from scrolling off the right side of KNode's pane
for threads.

In any case, to make sense of an article with attributions snipped, you need
to find the previous article to know who wrote what. If there are
quotations from multiple posters, it soon gets annoying.

 

[Richard Heathfield]

santosh said:

Removing [attributions] makes the discussion hard to follow for
those without threaded newsreaders.

KNode is a threaded news reader, so why the noise?

I have it in a mode which shows only unread articles,

Furthermore, it is not "noise" to plead for good manners on behalf of other
people. Just because you and I have threaded newsreaders, that doesn't
mean that everyone else does.

<snip>

 

[Kenny McCormack]

ptn wrote:

[CBFalconer wrote the text below]

Any ideas are welcome.

I suggest you first fix the above errors/oversights, and limit the
line length to 72 chars. The best way to handle malloc's is:

if (!(p = malloc(N * sizeof *p))) /* recovery code */;
else /* successful malloc, carry on */

You have given me a lot more information than what I'd expected. I
learned a lot

Please don't snip attributions, i.e., those lines beginning with "so-and-so
wrote:"

Removing them makes the discussion hard to follow for those without threaded
newsreaders.

KNode is a threaded news reader, so why the noise?

It is (feigned) concern for "the common man".

As I've pointed out several times in the past, the ethos of this NG is
very similar to that of organized (faith-based) religion. One of the
attributes of successful religions is that it has to be accessible by
everyone - but comprehensible only by the elite. That's a key part of
it all.

Note: In the above, I am assuming that you (rgrdev) have sussed out that
he (santosh) *is* running a threaded newsreader - hence the wonder at
his concern. I haven't taken the time to analyze people's newsreaders,
so I'm taking this on face value.

 

[Keith Thompson]

ptn wrote:

[CBFalconer wrote the text below]

You have given me a lot more information than what I'd expected. I
learned a lot

Please don't snip attributions, i.e., those lines beginning with "so-and-so
wrote:"

Removing them makes the discussion hard to follow for those without threaded
newsreaders.

Removing attributions makes the discussion hard to follow even for
those of us who do use threaded newsreaders. I read one article at a
time, and I don't usually go back to previous articles that I've
already read. I *can* (usually) go back to the parent article to see
who wrote it, but it's inconvenient, especially when I'm
simultaneously following dozens of threads as they develop over
periods of weeks.

Of course, the trolls have jumped on santosh's perfectly reasonable
suggestion and made a much bigger deal out of this than it needs to
be.

ptn just made a minor error in posting a followup, that's all. Given
the exemplary attitude he's displayed above, I suspect he won't repeat
the error.