Summary: | mathematical functions like sin, exp,... unusable in python scripts | ||
---|---|---|---|
Product: | [Applications] kig | Reporter: | Maurizio Paolini <maurizio.paolini> |
Component: | general | Assignee: | David E. Narvaez <david.narvaez> |
Status: | REOPENED --- | ||
Severity: | normal | CC: | aspotashev, encukou, hrvoje.senjan, kevin.kofler, rdieter |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1238113 | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
kig file that exposes the problem
explicitly use QLibrary to load libpython (like pykde does) |
Description
Maurizio Paolini
2014-06-08 18:19:32 UTC
Does this work? def calc( arg1 ): x = arg1.value() y = math.sin(x) return DoubleObject(y) It does not work either: The Python Interpreter generated the following error output: NameError: global name 'math' is not defined File "<string>", line 9, in calc Traceback (most recent call last): (In reply to comment #1) > Does this work? > > def calc( arg1 ): > x = arg1.value() > y = math.sin(x) > return DoubleObject(y) How about importing math directly? def calc( arg1 ): import math x = arg1.value() y = math.sin(x) return DoubleObject(y) I cannot reproduce this in Gentoo so I am pretty sure this will boil down to something specific to Fedora. Technically, Kig's code already imports math and its contents but for some reason it is not sticking when the code is executed. I still get an error, now it reads: The Python Interpreter generated the following error output: ImportError: /usr/lib/python2.7/lib-dynload/math.so: undefined symbol: PyFloat_Type File "<string>", line 8, in calc Traceback (most recent call last): In addition, I noticed also an error appearing in the console running "kig": $ Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /usr/lib/python2.7/lib-dynload/math.so: undefined symbol: PyFloat_Type The exact same error is displayed also for the previous scripts. Trying "ldd -r /usr/lib/libboost_python.so" gives a long list of undefined symbols, among which I also find PyFloat_Type (https://bugzilla.redhat.com/show_bug.cgi?id=1101626, comment 6) (In reply to comment #3) > How about importing math directly? > > def calc( arg1 ): > import math > x = arg1.value() > y = math.sin(x) > return DoubleObject(y) > > I cannot reproduce this in Gentoo so I am pretty sure this will boil down to > something specific to Fedora. Technically, Kig's code already imports math > and its contents but for some reason it is not sticking when the code is > executed. OK, then it is a linking error so I'll close this as downstream. If Fedora investigates and finds out it is something to do with Kig I will reopen and see what can be fixed. David, what version of boost and python are you using to test? does your libboost_python contain undefined symbols too? David, any idea regarding comment #6? (In reply to Rex Dieter from comment #6) > David, what version of boost and python are you using to test? does your > libboost_python contain undefined symbols too? Python 2.7.7 Boost 1.55.0 My Boost-Python library is properly linked. Boost linkage was fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1102667 and the problem still occurs. (In reply to Kevin Kofler from comment #9) > Boost linkage was fixed: > https://bugzilla.redhat.com/show_bug.cgi?id=1102667 > and the problem still occurs. Please post the output of $ ldd -r /usr/lib64/python2.7/lib-dynload/math.so and your boost-python version. I have a 32 bit architecture, here is the result for me: $ rpm -q boost-python boost-python-1.55.0-8.fc21.i686 $ ldd -r /usr/lib/python2.7/lib-dynload/math.so linux-gate.so.1 => (0xb7800000) libpthread.so.0 => /lib/libpthread.so.0 (0xb77b3000) libc.so.6 => /lib/libc.so.6 (0xb75e6000) /lib/ld-linux.so.2 (0x49ceb000) undefined symbol: PyFloat_Type (/usr/lib/python2.7/lib-dynload/math.so) undefined symbol: sinh (/usr/lib/python2.7/lib-dynload/math.so) undefined symbol: ceil (/usr/lib/python2.7/lib-dynload/math.so) [...] undefined symbol: log1p (/usr/lib/python2.7/lib-dynload/math.so) undefined symbol: PyMem_Malloc (/usr/lib/python2.7/lib-dynload/math.so) for a total of 64 undefined symbols Thanks Murizio, please post that output in the bug report in Comment 9. As a workaround while RedHat fixes linkage problems, you can run kig from the console with $ LD_PRELOAD=/usr/lib64/libpython2.7.so.1.0 kig --nofork or the lib folder if you are using 32 bits. I cannot reproduce the problem now, trying the example from Comment #1, I get: The Python Interpreter generated the following error output: TypeError: calc() takes exactly 1 argument (0 given) The Python interpreter caught an error during the execution of your script. Please fix the script and click the Finish button again. Which at least implies stuff is getting loaded properly now. (In reply to Rex Dieter from comment #13) > Which at least implies stuff is getting loaded properly now. No, it means you didn't follow the steps on Comment 1: you need to click on the numeric label so that it will be passed as the first argument. I'm not a kig user, sorry, the directions didn't mention how to create a label specifically. How to do that? Or give some other simple test case? (In reply to Rex Dieter from comment #15) > I'm not a kig user, sorry, the directions didn't mention how to create a > label specifically. How to do that? To create a numeric label press N and then click anywhere in the drawing area. OK , I see I make a valid example now (and get no error), but I do see in console output still: Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: /usr/lib/python2.7/lib-dynload/math.so: undefined symbol: PyFloat_Type and do not get that when using LD_PRELOAD=/usr/lib64/libpython2.7.so.1.0 , odd though, since kig also is linking libpython You can create a numeric label by first creating a point, then right-click on the point and select "Add Text Label" and then "X-coordinate". a number should appear below the point, that is a numeric label that can be used as an argument (see comment 1) Sorry David for the cross-post... and thank you for the workaround, it works fine. However, unlike Rex, without the "LD_PRELOAD=" I cannot use mathematical functions! Created attachment 93431 [details]
kig file that exposes the problem
To aid in investigating the problem, this kig file exposes it.
the command "kig mathbug.kig" should display a sinusoidal curve (as a locus)
it works with "LD_PRELOAD /usr/lib/libpython2.7.so kik mathbug.kig"
but it produces an "[invalid]" object otherwise.
https://projects.kde.org/projects/kde/kdeedu/kig/repository/revisions/master/entry/scripting/python_scripter.cc#L384 Essentially does: Py_Initialize(); ... s = newstring( "import math; from math import *;" ); ... PyRun_SimpleString( s ); and this is where it fails to load anything from math (per comment #1 above). Comparing with pykde4, I see it (essentially) does an extra dlopen on libpython to ensure symbols are available at runtime, does kig need to do something similar here? See also: https://projects.kde.org/projects/kde/kdebindings/python/pykde4/repository/revisions/master/entry/kpythonpluginfactory/kpythonpluginfactory.cpp#L98 Created attachment 93445 [details]
explicitly use QLibrary to load libpython (like pykde does)
This patch seems to fix the issue for me. Would you prefer I post to reviewboard?
I am not going to include workarounds for distro bugs in Kig. You can either bug Fedora about their broken linkage or apply that patch in the Kig package for Fedora. In any case, stop reopening this bug since there is nothing to fix in Kig. It's not a distro bug, python modules do not link libpython by default. Are you saying how pykde works is wrong then? :) i can reproduce the problem in openSUSE FWIW (In reply to Hrvoje Senjan from comment #27) > i can reproduce the problem in openSUSE FWIW Do you have undefined symbols in math.so? (See comment 11). Let me correct comment #18, kig doesn't link python itself, only kigpart does, which may be part of the problem here. Hi, one of Python maintainers in Fedora here (though I've never heard of kig before). math.so is an extension module *for Python*. Loading Python's math module before loading Python itself doesn't make much sense to me. Comment #22 mentions that kig calls "Py_Initialize" before importing the math library. Where does the symbol "Py_Initialize" come from if libpython is not yet loaded? Note that Fedora does build math, among others, as a shared module. This is not the upstream default, but I do believe it's valid configuration. (See https://hg.python.org/cpython/file/53975668c9e9/Modules/Setup.dist -- Fedora has the lines "*shared*" and "math mathmodule.c _math.c" uncommented, among others.) (In reply to Petr Viktorin from comment #30) > Note that Fedora does build math, among others, as a shared module. This is > not the upstream default, but I do believe it's valid configuration. (See > https://hg.python.org/cpython/file/53975668c9e9/Modules/Setup.dist -- Fedora > has the lines "*shared*" and "math mathmodule.c _math.c" uncommented, among > others.) So distro plays around with the default installation settings, distro breaks an application, nothing new here. I still do not understand why are we discussing this in the KDE bug tracker. (In reply to David E. Narvaez from comment #31) > I still do not understand why are we > discussing this in the KDE bug tracker. I believe we're discussing to find out why there's unexpected behavior in systems where Python is configured differently. We assumed you might be interested; if not, just remove yourself or reassign. No one is forcing you to investigate or fix this; Fedora already includes the patch. To get Fedora out of the picture, I reproduced the same `ldd -r` output with Python-2.6.9 source tarball, with math as a shared library. If you believe building math as a shared library this counts as misconfiguring Python, I can open a Python bug to improve docs or remove the option. As a Python developer, I'd be interested in knowing the root cause, so that possibly Python can be improved. (In reply to Petr Viktorin from comment #32) > I believe we're discussing to find out why there's unexpected behavior in > systems where Python is configured differently. We assumed you might be > interested; if not, just remove yourself or reassign. No one is forcing you > to investigate or fix this; Fedora already includes the patch. Can you add the URL to where this specific bug is being tracked in Fedora to the URL field of this bug? Adding reference to downstream bug (fedora 22) https://bugzilla.redhat.com/show_bug.cgi?id=1238113 as requested There's also an older (fedora 21) https://bugzilla.redhat.com/show_bug.cgi?id=1101626 which is essentially the same issue. Reviewboard submitted, https://git.reviewboard.kde.org/r/126549/ *** Bug 388241 has been marked as a duplicate of this bug. *** |