classification
Title: Some functions in pymath.c should be moved elsewhere.
Type: Stage:
Components: Build Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: mark.dickinson, martin.panter, rpetrov
Priority: normal Keywords:

Created on 2009-12-15 19:19 by mark.dickinson, last changed 2015-06-17 17:04 by mark.dickinson. This issue is now closed.

Messages (9)
msg96455 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-15 19:19
The Python/pymath.c file currently defines substitutes for some C99 libm 
functions (e.g., log1p), for the benefit of platforms that don't implement 
those functions.
It's compiled into the main Python executable.

There are (at least) two problems with this approach:

(1) on a platform that doesn't have (for example) log1p, we end up 
exporting the symbol _log1p from the main Python executable.  At the very 
least, this should have a _Py prefix.  Moreover, since log1p is only 
needed by the math and cmath modules, and not by the Python interpreter 
itself, python.exe shouldn't really be exporting it in the first place.

(2) It may not work!  As an experiment, I tried adding a new function 
expm1_alt to pymath.c, declaring it in Include/pymath.h with PyAPI_FUNC, 
and using it in Modules/mathmodule.c; but the function ended up not being 
visible to the math module:  the math module failed to build, with an 
error message:

dlopen(build/lib.macosx-10.4-i386-2.7/math.so, 2): Symbol not found: 
_expm1_alt

When I moved the function to a different source file (I picked 
Objects/longobject.c, for no particularly good reason) the new function 
became visible and the build succeeded.

The reason for the above behaviour appears to be (I'm guessing a little 
bit) that on my platform (OS X 10.6), none of the functions from pymath.c 
is needed in the main python executable, so when creating python.exe the 
linker ignores *all* the symbols from pymath.c.  So while libpython2.7.a 
exports _expm1_alt, python.exe does not.

I'm not sure what the best way to reorganize this setup is.
msg96464 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-15 20:00
Incidentally, the build failure described earlier can be fixed by creating python.exe with:

gcc -u _PyMac_Error -o python.exe Modules/python.o -ldl -Wl,-force_load,libpython2.7.a -framework CoreFoundation

instead of with:

gcc -u _PyMac_Error -o python.exe Modules/python.o libpython2.7.a -ldl -framework CoreFoundation
msg96499 - (view) Author: Roumen Petrov (rpetrov) * Date: 2009-12-16 22:17
In general those functions has to be part of, lets call it "python
runtime/portable interface" . With current build system you may create a
build-in module lets call it mathport and to add some functions .
To the list a will add function atan2 from math module. I don't know why
the test cases for cmath pass on platforms with non-expected behaviour
of atan2-may be build boots lack those platforms. To me is expected for
all platforms on which "tanh preserves the sign of zero" configure test
case fail atan2 to fail too and cmath functions that use atan2 to fail.
msg96500 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-16 22:31
For the recently added expm1 function (see issue #3366), I've put the 
substitute code in a new file Modules/_math.c, that's linked into math.so.  
I plan to move the other substitute libm functions from pymath.c into this 
file, and to link _math.c into the cmath module as well as the math 
module.

Roumen, I'm not sure I understand your comments about atan2.  Is there 
some link between atan2 and tanh that I'm not aware of?  Which platforms 
have unexpected behaviour for atan2?
msg96502 - (view) Author: Roumen Petrov (rpetrov) * Date: 2009-12-17 00:16
May be is good to add depends=['_math.h'], for modules in setup.py.

About atan2 - lets see comments in mathmodule and configure test. The
cmath test case pass on freebsd as buildbot is for for 7.2. What about
freebsd 6.2 ?
Also I don't think that python cmath tests will pass with MSVC before
8.0. It is based on my tests in the past with different MSVC runtimes.
In my notes for msvc 7.0.2600 result of 2.*atan2(-0,1.4142135623730951)
is 0(zero) instead -0.
msg96507 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-17 08:53
So the configure test for tanh(-0.0) is purely informational:  it doesn't 
affect the behaviour of the built Python in any way.  I agree that the 
test is imperfect, in that if atan2 is also non-conformant on the given 
platform then the sign issue with tanh may go undetected, but all that 
happens in that case is that we get a bogus 'preserves sign of -0 ... yes' 
message in the configure output.

The wrapper for atan2 in Modules/mathmodules.c is a separate issue; it 
should ensure that we get the right behaviour for atan2 on all platforms,
including msvc 7.0.  I can't immediately see any reason why it wouldn't be 
working as intended.

> I don't think that python cmath tests will pass with MSVC before
8.0.

Which test(s) do you think will fail?

> May be is good to add depends=['_math.h'], for modules in setup.py.

Good point---thanks!  Done in r76865 (trunk), r76867 (py3k).
msg96754 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-12-21 15:28
Moved atanh, asinh, acosh, log1p from pymath.c to Modules/_math.c in 
r76978 (trunk), r76980 (py3k).
msg245430 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-06-17 03:49
I suspect the change here causes _math.c to be compiled to the same object file twice, and there is a race condition when the compilations are concurrent. See Issue 24421.
msg245443 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2015-06-17 17:04
Yes, there are almost certainly better ways to organize the build here. 

A hacky solution might be to simply #include _math.c in the two other files that need it.
History
Date User Action Args
2015-06-17 17:04:33mark.dickinsonsetmessages: + msg245443
2015-06-17 03:49:27martin.pantersetnosy: + martin.panter
messages: + msg245430
2009-12-21 15:28:10mark.dickinsonsetstatus: open -> closed

messages: + msg96754
priority: normal
assignee: mark.dickinson
resolution: fixed
2009-12-17 08:53:35mark.dickinsonsetmessages: + msg96507
2009-12-17 00:16:51rpetrovsetmessages: + msg96502
2009-12-16 22:31:19mark.dickinsonsetmessages: + msg96500
2009-12-16 22:17:05rpetrovsetnosy: + rpetrov
messages: + msg96499
2009-12-15 20:00:27mark.dickinsonsetmessages: + msg96464
2009-12-15 19:19:34mark.dickinsoncreate