classification
Title: mathmodule.c fails to compile due to missing math_log1p() function
Type: Stage:
Components: Extension Modules Versions: Python 2.6
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: alanh, mark.dickinson
Priority: normal Keywords:

Created on 2009-04-28 13:01 by alanh, last changed 2009-04-28 18:19 by mark.dickinson. This issue is now closed.

Messages (11)
msg86733 - (view) Author: Alan Hourihane (alanh) Date: 2009-04-28 13:01
mathmodule.c fails to compile because math_log1p() is missing in
mathmodule.c...

gcc -fno-strict-aliasing -DNDEBUG -O2 -pipe -fomit-frame-pointer  -I.
-IInclude -I./Include   -DPy_BUILD_CORE  -c ./Modules/mathmodule.c -o
Modules/mathmodule.o
./Modules/mathmodule.c: In function 'math_log1p':
./Modules/mathmodule.c:353: error: 'log1p' undeclared (first use in this
function)
./Modules/mathmodule.c:353: error: (Each undeclared identifier is
reported only once
./Modules/mathmodule.c:353: error: for each function it appears in.)
./Modules/mathmodule.c: In function 'math_fsum':
./Modules/mathmodule.c:574: warning: passing argument 1 of 'PyFPE_dummy'
discards qualifiers from pointer target type
msg86738 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-28 13:52
Thanks for the report.

Could you please tell me what platform you're on?

And does the configure script detect that log1p is available?  (There
should be a line in the (stdout) output of the configure script that
looks something like:

checking for log1p... yes

except that in your case I'm guessing that you get a 'no' there rather
than a 'yes'.  Is that true?
msg86739 - (view) Author: Alan Hourihane (alanh) Date: 2009-04-28 13:57
I do have log1p() available...

checking for log1p... yes

And it's in math.h and libm.a on my system.

I still can't see any reference to math_log1p() in mathmodule.c which is
why it's barfing.
msg86740 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-28 14:02
math_log1p should be produced by the line

FUNC1(log1p, log1p, 1, ...

FUNC1 is a macro that (in this instance) creates the math_log1p function.

The original error message that you posted seems to say that it's log1p
that's undeclared, not math_log1p.

It's strange that log1p isn't being picked up.

What's your operating system?
msg86743 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-28 14:20
It might also be helpful if you could tell me how you're building
Python (what configure options, etc.), and which version of the
source you have---is this the 2.6.2 tarball from python.org, or
a recent svn;  if the latter, which revision?

Thanks!
msg86745 - (view) Author: Alan Hourihane (alanh) Date: 2009-04-28 14:29
Ah. right. I see what you mean about the macro expansion.

So I'm on an Atari FreeMiNT platform which is an m68k box which has no
shared libraries so I'm setting up for static only via Setup.dist.

Note that cmathmodule.c compiles fine and that does reference log1p() too.

This is basic 2.6.2 from the tarball.
msg86746 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-28 14:45
> Note that cmathmodule.c compiles fine and that does reference
> log1p() too.

Now that's *really* peculiar.  I can't imagine why one would work and
the other not.  Some ideas about how to proceed from here:

- try doing a debug build (./configure --with-pydebug) to see if
  the errors still occur.  (They probably will, but you never know...)

- What happens if you add an

#include <float.h>

after the line

#include "Python.h"

in mathmodule.c?  I'm clutching at straws here, but that's the only
difference I can see between cmathmodule.c and mathmodule.c that might
be affecting this.  Your error output from gcc looks as though either:

- math.h isn't being included, or
- you've got more than one version of math.h, and the wrong one's
  being included, or
- math.h doesn't declare log1p (but you've already said that it does).

What *should* be happening is that the line

#include "Python.h"

includes Python.h, which in turn includes pyport.h, which in turn
includes math.h.

It's also odd that this is the first function that fails.  If math.h
isn't being included somehow, then I'd also expect acosh, etc. to be
failing to build.

Do people really still use m68k. :-)
msg86750 - (view) Author: Alan Hourihane (alanh) Date: 2009-04-28 15:43
It's ok, I see what the problem is. It's GCC's headers that are causing
trouble.

Closing.
msg86752 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-28 16:41
I'm glad you sorted it out. :)

Any chance you could tell us what the fix was, in case anyone else runs 
into something similar?  Or is that unlikely to happen?

Also, while you're there, I have a favour to ask:  could you tell me
what the result of doing 

>>> 1e16 + 2.99999

is on that platform?  It's not often I get to find out much about Python 
on m68k, and I'm curious to know whether it has the same double rounding 
problems as x86.

Thanks!
msg86753 - (view) Author: Alan Hourihane (alanh) Date: 2009-04-28 16:47
GCC was munging math.h when it did fixincludes. I'm fixing the GCC port now.

Result of 1e16+2.99999 is...

10000000000000002.00
msg86758 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-04-28 18:19
Many thanks.  Looks like no double rounding then;  that's good news.
(32-bit Linux on x86 typically produces 10...0004.0 for this example).
History
Date User Action Args
2009-04-28 18:19:58mark.dickinsonsetmessages: + msg86758
2009-04-28 16:47:28alanhsetmessages: + msg86753
2009-04-28 16:41:31mark.dickinsonsetmessages: + msg86752
2009-04-28 15:43:52alanhsetstatus: open -> closed

messages: + msg86750
2009-04-28 14:45:58mark.dickinsonsetmessages: + msg86746
2009-04-28 14:29:26alanhsetmessages: + msg86745
2009-04-28 14:20:36mark.dickinsonsetmessages: + msg86743
2009-04-28 14:02:11mark.dickinsonsetmessages: + msg86740
2009-04-28 13:57:02alanhsetmessages: + msg86739
2009-04-28 13:52:26mark.dickinsonsetassignee: mark.dickinson

messages: + msg86738
nosy: + mark.dickinson
2009-04-28 13:01:43alanhcreate