Message96455
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. |
|
Date |
User |
Action |
Args |
2009-12-15 19:19:49 | mark.dickinson | set | recipients:
+ mark.dickinson |
2009-12-15 19:19:48 | mark.dickinson | set | messageid: <1260904788.96.0.184476026521.issue7518@psf.upfronthosting.co.za> |
2009-12-15 19:19:34 | mark.dickinson | link | issue7518 messages |
2009-12-15 19:19:33 | mark.dickinson | create | |
|