See upstream bug for details: http://bugs.python.org/issue4303
Please reopen bug 275311 and make this bug block it.
Was 2.5.4-r2 or 2.5.2-r* also broken? Is 2.6* broken? Also please attach build log.
Created attachment 202457 [details] build.log (In reply to comment #2) > Was 2.5.4-r2 or 2.5.2-r* also broken? Is 2.6* broken? > Also please attach build log. > 2.5.2* worked. 2.6.2-r1 also works. Maybe it (2.6) should just be stabilized. Build log attached.
Relevant part: building '_ctypes' extension creating build/temp.linux-armv6j-2.5/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes creating build/temp.linux-armv6j-2.5/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/libffi creating build/temp.linux-armv6j-2.5/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/libffi/src creating build/temp.linux-armv6j-2.5/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/libffi/src/arm armv6j-gentoo-linux-gnueabi-gcc -pthread -fPIC -fno-strict-aliasing -DNDEBUG -Os -march=armv6j -pipe -mtune=arm1136jf-s -mfpu=vfp -Wa,--noexecstack -I. -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/./Include -Ibuild/temp.linux-armv6j-2.5/libffi/include -Ibuild/temp.linux-armv6j-2.5/libffi -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Include -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4 -c -I. -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/./Include -Ibuild/temp.linux-armv6j-2.5/libffi/include -Ibuild/temp.linux-armv6j-2.5/libffi -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Include -I/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4 -c /var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/_ctypes.c -o build/temp.linux-armv6j-2.5/var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/_ctypes.o In file included from /var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/_ctypes.c:126: /var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/ctypes.h:72: error: expected specifier-qualifier-list before 'ffi_closure' /var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/_ctypes.c: In function 'CFuncPtr_new': /var/tmp/portage/dev-lang/python-2.5.4-r3/work/Python-2.5.4/Modules/_ctypes/_ctypes.c:2955: error: 'CThunkObject' has no member named 'pcl'
2.6 was stabilized, so closing
The bug may be fixed in python-2.6 but the problem is not. To get python-2.6 you need EAPI2 and therefore you need a newer version of portage which requires >=python-2.5, and the only available version of python in the current portage tree which can be emerged with EAPI1 and fulfill this requirement is... python-2.5.4 ! So if you did not emerge python-2.5.2 while it was available in portage you are basically stuck with python-2.4.4 and EAPI1. The latest experimental stage tarballs for arm (2008.0) are still based on python-2.4.4 and therefore suffer from this very problem (and you can not use these tarballs to make a quickpkg of python to use as a temporary fix to emerge python-2.6). Personnally, I solved this issue by pulling back from sources.gentoo.org an ebuild of python-2.5.2 into my local overlay. To really fix this problem, you might consider doing one of the following things: - pulling back python-2.5.2 into the portage tree; - providing an EAPI1-compatible ebuild of python-2.6; - backporting the fix for python-2.5.4. I'm not sure it is worth doing it for the mainstream portage tree, but at least the arm overlay should do it.
