Re: [trinity-devel] kdeutils FTBFS - error: 'PyString_CheckExact' was not declared in this scope
What scope should it be declared in? When building with autotools, I do not experience this failure.
One idea is you are using a bleeding edge Python. Those Python developers are like grocery store managers: they have to keep changing the location of things to appear like they actually do something constructive.
The tdeutils/superkaramba/src/meter_python.cpp file is the only place I find the function PyString_CheckExact being used. The meter_python.cpp has the following include:
#include <Python.h>
I have Python 2.7 installed. The Python.h header file has a bunch of other header file includes, one of which PyString_CheckExact is defined.
Perhaps look into where PyString_CheckExact is defined in your version of Python. My guess is your version of Python.h no longer contains an include where PyString_CheckExact is defined or perhaps PyString_CheckExact has been replaced by a different function.
Just guessing.
The only thing certain in free/libre software is tomorrow somebody upstream will break something that works today.
Darrell
On 02/08/2014 11:38 PM, Darrell Anderson wrote:
What scope should it be declared in? When building with autotools, I do not experience this failure.
One idea is you are using a bleeding edge Python. Those Python developers are like grocery store managers: they have to keep changing the location of things to appear like they actually do something constructive.
The tdeutils/superkaramba/src/meter_python.cpp file is the only place I find the function PyString_CheckExact being used. The meter_python.cpp has the following include:
#include <Python.h>
I have Python 2.7 installed. The Python.h header file has a bunch of other header file includes, one of which PyString_CheckExact is defined.
Perhaps look into where PyString_CheckExact is defined in your version of Python. My guess is your version of Python.h no longer contains an include where PyString_CheckExact is defined or perhaps PyString_CheckExact has been replaced by a different function.
Just guessing.
The only thing certain in free/libre software is tomorrow somebody upstream will break something that works today.
Darrell
Your guesses are pretty 'spot-on' normally. Arch has python 3.3.3, but also includes python 2.7.6 as 'python2'. We should be able to patch the superkaramba cmake file to call python2 instead of python which should solve the problem.
On Sun, 09 Feb 2014 00:22:30 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 02/08/2014 11:38 PM, Darrell Anderson wrote:
I have Python 2.7 installed. The Python.h header file has a bunch of other header file includes, one of which PyString_CheckExact is defined.
Perhaps look into where PyString_CheckExact is defined in your version of Python. My guess is your version of Python.h no longer contains an include where PyString_CheckExact is defined or perhaps PyString_CheckExact has been replaced by a different function.
Your guesses are pretty 'spot-on' normally. Arch has python 3.3.3, but also includes python 2.7.6 as 'python2'. We should be able to patch the superkaramba cmake file to call python2 instead of python which should solve the problem.
A lot of things about string handling changed between Python 2 and Python 3, and the problems associated with this are one of the main reasons Python 2 is still a going concern. For practical purposes, it's easiest to treat the two as separate languages, rather than as two versions of the same language, because most code is surprisingly difficult to transfer.
E. Liddell
On 02/09/2014 07:27 AM, E. Liddell wrote:
On Sun, 09 Feb 2014 00:22:30 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 02/08/2014 11:38 PM, Darrell Anderson wrote:
I have Python 2.7 installed. The Python.h header file has a bunch of other header file includes, one of which PyString_CheckExact is defined.
Perhaps look into where PyString_CheckExact is defined in your version of Python. My guess is your version of Python.h no longer contains an include where PyString_CheckExact is defined or perhaps PyString_CheckExact has been replaced by a different function.
Your guesses are pretty 'spot-on' normally. Arch has python 3.3.3, but also includes python 2.7.6 as 'python2'. We should be able to patch the superkaramba cmake file to call python2 instead of python which should solve the problem.
A lot of things about string handling changed between Python 2 and Python 3, and the problems associated with this are one of the main reasons Python 2 is still a going concern. For practical purposes, it's easiest to treat the two as separate languages, rather than as two versions of the same language, because most code is surprisingly difficult to transfer.
E. Liddell
Yes, I understand what happened, and I've been slowly working through a python fix that will work for python2 and python3. Basically following Darrell's grocery store manager analogy, python moved everything from isle PyString_foo to isle PyBytes_foo and broke all customer expectation of where to find them. However, being a good little grocery store manager, python left a little sign on PyString_'s isle, in an ad named bytesobject.h that tells customers:
bytesobject.h:11:#define PyBytes_FromStringAndSize PyString_FromStringAndSize bytesobject.h:12:#define PyBytes_FromString PyString_FromString ...
So that when customers move to the new isle to shop, they will still be able to checkout just as they always have. However, moving to the new isle to find PyString_ is a difficult matter with all sorts of mops, brooms, spills and cleanups blocking the way.
But there appears another option. It seems that the manager, cmake, holds the key to allow customers to continue to shop on the old PyString_ isle by simply changing the checkout from /usr/bin/python to /usr/bin/python2, but as with most managers, the key is misplaced somewhere in the bowels of the storeroom in a box labeled autotools or maybe cmake, but the manager cannot be sure as his memory is clouded by many many trips to the checkout line since he last recalls seeing the key....
-
Darrell Anderson -
David C. Rankin -
E. Liddell