seen on the mipsel buildbot

running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
  File "./setup.py", line 1880, in <module>
    main()
  File "./setup.py", line 1875, in main
    'Lib/smtpd.py']
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/core.py",
line 152, in setup
    dist.run_commands()
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 975, in run_commands
    self.run_command(cmd)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 995, in run_command
    cmd_obj.run()
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build.py",
line 134, in run
    self.run_command(cmd_name)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/cmd.py",
line 333, in run_command
    self.distribution.run_command(command)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/dist.py",
line 995, in run_command
    cmd_obj.run()
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py",
line 343, in run
    self.build_extensions()
  File "./setup.py", line 201, in build_extensions
    build_ext.build_extensions(self)
  File
"/home/doko/buildarea/trunk.klose-debian-mipsel/build/Lib/distutils/command/build_ext.py",
line 469, in build_extensions
    self.build_extension(ext)
  File "./setup.py", line 234, in build_extension
    if not self.configure_ctypes(ext):
  File "./setup.py", line 1684, in configure_ctypes
    execfile(ffi_configfile, globals(), fficonfig)
  File "build/temp.linux-mips-2.7-pydebug/libffi/fficonfig.py", line 32,
in <module>
    ffi_sources += ffi_platforms['MIPS']
KeyError: 'MIPS'
[47349 refs]
make: *** [sharedmods] Error 1

It's actually due to the merge of the libffi3 branch back in March,
which removed the logic for configure to deal with MIPS in
fficonfig.py.in. I've attached a patch which allows the build to work
correctly on the QEMU instance of the MIPSEL machine I have.

Adding this as affecting the 2.6 branch as well, since I initially
tested on a 2.6.1 tarball with this problem.

Would it be possible to get some feedback as to whether this is a
candidate for Python 2.6 on this patch?

May I propose a simple py-issue-4305.patch. Let me know if patch work
for you.

Not entirely. I applied what you had for the autoconf section to my
configure, since I do not have autoconf installed in my environment. 

Specifically, this part of configure is what's messing with the build:

if test x$TARGET = xMIPS; then
  MIPS_TRUE=
  MIPS_FALSE='#'
else
  MIPS_TRUE='#'
  MIPS_FALSE=
fi

Since the target is being renamed to MIPS_LINUX or MIPS_IRIX, this test
assumes the target is not MIPS.

The patch you have gets past the build break, but doesn't actually
compile what I believe is a working libffi for MIPS.

So I attach patch with changes in Modules/_ctypes/libffi/configure for
the tests.

Is there any movement on this perchance?  Just bumped into this on my
MIPS platform and discovered this bug.

Joshua Kinard schrieb:
> Joshua Kinard <kumba@gentoo.org> added the comment:
> 
> Is there any movement on this perchance?  Just bumped into this on my
> MIPS platform and discovered this bug.

There is no MIPS buildbot at the moment, and I'm unclear which one
of the patches solves the issue.

I wonder if fixes for issues like these (ctypes build errors on some
plaforms) could be verified by using cross compilers on linux?

Thomas, the report is for:
------------
ffi_sources += ffi_platforms['MIPS']
KeyError: 'MIPS'
------------
you may test patch without to cross-compile. As example create two
directories.

In first one run:
..../Modules/_ctypes/libffi/configure --host=mips-pc-linux F77=no CXX=no
and in the second one:
..../Modules/_ctypes/libffi/configure --host=mips-sgi-irix5.0 FC=no

Compare directories as example:
$ diff -ur --exclude=config.* [DIR1] [DIR2]

I've applied py-issue-4305.patch and reran configure 2.61. Committed as
rev 72081 (trunk), 72082 (py3k branch), 72083 (release26-maint branch),
72084 (release30-maint branch).

Can someone please confirm that it works now, so that I can close this
issue?

Tested myself, on a mipsel debian qemu instance.