Orange Forum • View topic - Build Problem on Linux AMD 64

Build Problem on Linux AMD 64

Report bugs (or imagined bugs).
(Archived/read-only, please use our ticketing system for reporting bugs and their discussion.)
Forum rules
Archived/read-only, please use our ticketing system for reporting bugs and their discussion.

Build Problem on Linux AMD 64

Postby neuroman » Sat May 12, 2007 2:33

When trying to rebuild from source from snap-2001-05-10 I get the following:

Code: Select all
...
g++ -fPIC -fpermissive -w -DLINUX -DORANGE_EXPORTS -O3 -c dictproxy.cpp -o obj/dictproxy.o
dictproxy.cpp: In function ‘PyObject* PyOrange_DictProxy_update(TPyOrange_DictProxy*, PyObject*)’:
dictproxy.cpp:195: error: cannot convert ‘int*’ to ‘Py_ssize_t*’ for argument ‘2’ to ‘int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)’
dictproxy.cpp: In function ‘PyObject* PyOrange_DictProxyIter_iternext(TPyOrange_DictyProxyIter*)’:
dictproxy.cpp:579: error: cannot convert ‘int*’ to ‘Py_ssize_t*’ for argument ‘2’ to ‘int PyDict_Next(PyObject*, Py_ssize_t*, PyObject**, PyObject**)’
make[1]: *** [obj/dictproxy.o] Error 1
make[1]: Leaving directory `/home/offero/Downloads/orange/source/orange'
make: *** [all] Error 1


I am on Ubuntu Feisty AMD 64.

Postby Janez » Sat May 12, 2007 10:25

Py_ssize_t is new in Python 2.5 to support 64-bit machines.

To modify Orange for 64-bit platforms, we'd need to go through tens of thousands lines of code and change some int's into Py_ssite_t. I don't think we'll have time for this in near future. Besides, we all still work on 32-bit machines for now, so we even can't test it.

AFAIK, the usual 32-bit orange binaries work well on 64-bit Windows. Pardon my ignorance, but can't you use it like that?

Postby neuroman » Sat May 12, 2007 15:00

There has to be a better way than modifying all that source code. As far as I know, I cannot just use your 32bit compiled binaries to run the program. I will try, but I believe I will have to use a chroot to have them work correctly. This is not what I would want, but maybe i'll be able to help find a fix for 64 bit. Honestly, I don't see how 64 bit architectures could be ignored for a project like this, especially with their ability to handle larger numbers more efficiently. Thanks for the quick response.

Postby Guest » Fri May 18, 2007 9:23

I recently compiled orange on 64bit Feisty, by simply adding a few (Py_ssize_t*) casts whenever the compiler complained. I was done in under 5 min.
However this probably isn't a safe fix as the definition of Py_ssize_t can change in the future (or vary depending on the architecture). It is currently typedef -ed as int

Postby Janez » Fri May 18, 2007 10:20

Thanks. Could you send me a diff to janez.demsar, a t fri.uni-lj.si?

I wouldn't add it to the code yet, precisely for the reason you mentioned - when some parts change to Py_ssize_t, the whole code has to do it, not just the parts where the compiler complained. But I'd like to see at which places it happens.

But I wonder - if Py_ssize_t is typedefed as int and we now use int instead of typedef, why does compiler complain? Are gcc (and the standard) more strict than I thought?


Return to Bugs