Im trying to compile Godot engine following the instructions here

When I run scons bin/godot as the tutorial says, I get the following error:

scons: Reading SConscript files ...
ImportError: cannot import name _args_from_interpreter_flags:
  File "/home/grayfox/github/godot2/godot/SConstruct", line 9:
    import multiprocessing
  File "/usr/lib64/python2.7/multiprocessing/__init__.py", line 65:
    from multiprocessing.util import SUBDEBUG, SUBWARNING
  File "/usr/lib64/python2.7/multiprocessing/util.py", line 40:
    from subprocess import _args_from_interpreter_flags

The SConstruct file starts this way:

EnsureSConsVersion(0,14);

import string
import os
import os.path
import glob
import sys
import methods
import multiprocessing
...

If I try to run python SConstruct I get an error complaining about missing functions defined by scons (i.e. the script fails after doing all the imports).

Commenting import multiprocessing fixes the issue but I don't want to modify that file, as I would have to revert the change if I ever make a pull request. The project is quite active so I believe this has something to do with my local configuration.

Any ideas why the script is failing to import _args_from_interpreter_flags only if I execute it via scons?

[UPDATE]

I did a fresh Gentoo install and the problem persists. I did some tests and I found this:

In a python terminal>

>>> import SCons.Script
>>> from subprocess import _args_from_interpreter_flags
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name _args_from_interpreter_flags
>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/site-packages/SCons/compat/_scons_subprocess.pyc'

But the output is different if I do this:

>>> import subprocess
>>> subprocess.__file__
'/usr/lib64/python2.7/subprocess.pyc'

So I update my question: Is this a bug? Can anybody reproduce it in other distros? If it's a bug, should I report it to Gentoo or to SCons?

[ANOTHER UPDATE]

Adding temp.extend([os.path.join(x, 'lib64') for x in prefs]) did't work, same error.

Adding print sys.path at the beginning of the compact module gives:

['/usr/lib64/python-exec/python2.7/scons-local-2.3.0',
 '/usr/lib64/python-exec/python2.7/scons-local',
 '/usr/lib64/python2.7/site-packages/lib32/scons-2.3.0',
 '/usr/lib32/scons-2.3.0',
 '/usr/local/lib32/scons-2.3.0',
 '/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons-2.3.0',
 '/usr/lib/python2.7/site-packages/scons-2.3.0',
 '/usr/local/lib/python2.7/site-packages/scons-2.3.0',
 '/usr/lib64/scons-2.3.0',
 '/usr/lib64/python2.7/site-packages/lib32/scons',
 '/usr/lib32/scons',
 '/usr/local/lib32/scons',
 '/usr/lib64/python2.7/site-packages/lib/python2.7/site-packages/scons',
 '/usr/lib/python2.7/site-packages/scons',
 '/usr/local/lib/python2.7/site-packages/scons',
 '/usr/lib64/scons',
 '/usr/lib64/python2.7/site-packages/RBTools-0.6-py2.7.egg',
 '/usr/lib64/python27.zip',
 '/usr/lib64/python2.7',      #It's here, so what's the problem?
 '/usr/lib64/python2.7/plat-linux2',
 '/usr/lib64/python2.7/lib-tk',
 '/usr/lib64/python2.7/lib-old',
 '/usr/lib64/python2.7/lib-dynload',
 '/usr/lib64/python2.7/site-packages',
 '/usr/lib64/python2.7/site-packages/gtk-2.0',
 '/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode']
有帮助吗?

解决方案 2

It's a bug in Gentoo's scons-2.3.0 and scons-2.3.1 ebuilds (see bug report). It has been fixed in versions 2.3.1-r1 and higher.

其他提示

It looks as if this isn't really a problem connected to SCons directly. You might have an alien "subprocess" module/package installed in your system. Also check out Cannot import name _args_from_interpreter_flags which seems to be related.

Based on your updated question: I tried to compile Godot on my machine (Python 2.7.3, SCons 2.3.1, Ubuntu 12.04 LTS) and it's running fine, so the problem is not related to the provided SConstruct (and its supporting build description files in subfolders). The "_scons_subprocess" module gets used only when the import of the original "subprocess.py" fails. So I suspect that the SCons start script sets up a wrong sys.path, which may happen under 64bit (see issue http://scons.tigris.org/issues/show_bug.cgi?id=2657 ).

After you added "temp.extend([os.path.join(x, 'lib64') for x in prefs])", your "print sys.path" statement shows paths like "/usr/lib64/python-exec" in its output. A Google search turned up the page http://forums.gentoo.org/viewtopic-t-985402-start-0.html for me. It describes an issue with Gentoo, where programs are installed as links to pip. Please follow the given advice and see if this fixes your problem.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top