Repository navigation
mathmodule.c fails to compile due to missing math_log1p() function #50115
Description
| BPO | 5865 |
|---|---|
| Nosy | @mdickinson |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/mdickinson'
closed_at = <Date 2009-04-28.15:43:52.446>
created_at = <Date 2009-04-28.13:01:43.819>
labels = ['extension-modules']
title = 'mathmodule.c fails to compile due to missing math_log1p() function'
updated_at = <Date 2009-04-28.18:19:58.259>
user = 'https://bugs.python.org/alanh'bugs.python.org fields:
activity = <Date 2009-04-28.18:19:58.259>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-04-28.15:43:52.446>
closer = 'alanh'
components = ['Extension Modules']
creation = <Date 2009-04-28.13:01:43.819>
creator = 'alanh'
dependencies = []
files = []
hgrepos = []
issue_num = 5865
keywords = []
message_count = 11.0
messages = ['86733', '86738', '86739', '86740', '86743', '86745', '86746', '86750', '86752', '86753', '86758']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'alanh']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue5865'
versions = ['Python 2.6']
Activity
alanh commentedon Apr 28, 2009
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
mdickinson commentedon Apr 28, 2009
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?
alanh commentedon Apr 28, 2009
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.
mdickinson commentedon Apr 28, 2009
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?
mdickinson commentedon Apr 28, 2009
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!
alanh commentedon Apr 28, 2009
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.
mdickinson commentedon Apr 28, 2009
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
after the line
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:
being included, or
What *should* be happening is that the line
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. :-)
alanh commentedon Apr 28, 2009
It's ok, I see what the problem is. It's GCC's headers that are causing
trouble.
Closing.
mdickinson commentedon Apr 28, 2009
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
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!
alanh commentedon Apr 28, 2009
GCC was munging math.h when it did fixincludes. I'm fixing the GCC port now.
Result of 1e16+2.99999 is...
10000000000000002.00
mdickinson commentedon Apr 28, 2009
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).