2017-09-06 4 views
1

Ich versuche, Subprozess32 mit meiner Python 2.7-Installation über Buildroot zu installieren. Es schien richtig zu installieren, aber wenn ich es auf dem Embedded-System zu importieren bekomme ich einen Fehler:Problem beim Importieren von Subprozess32

>>> import subprocess32 
/usr/lib/python2.7/site-packages/subprocess32.py:472: RuntimeWarning: The _posixsubprocess module is not being used. Child process reliability may suffer if your pro 
gram uses threads. 
    "program uses threads.", RuntimeWarning) 

diesen Weg folgend habe ich versucht _posixsubprocess

import _posixsubprocess 
Traceback (most recent call last): 
    File "<stdin>", line 1, in <module> 
ImportError: dynamic module does not define init function (init_posixsubprocess) 

subprocess32 eigene Version ist es zu haben scheint, zu importieren und es ist funktioniert in diesem Fall nicht?

Hier ist mein Make-Datei:

############################################################# 
# 
# Subprocess32 module for python 
# 
############################################################# 

SUBPROCESS32_VERSION = 3.2.7 
SUBPROCESS32_SOURCE = subprocess32-$(SUBPROCESS32_VERSION).tar.gz 
SUBPROCESS32_SITE = https://pypi.python.org/pypi/subprocess32 

SUBPROCESS32_DEPENDENCIES = python 

define SUBPROCESS32_BUILD_CMDS 
     (cd $(@D); $(HOST_DIR)/usr/bin/python setup.py build) 
endef 

define SUBPROCESS32_INSTALL_TARGET_CMDS 
     (cd $(@D); $(HOST_DIR)/usr/bin/python setup.py install --prefix=$(TARGET_DIR)/usr) 
endef 

$(eval $(call GENTARGETS,package,subprocess32)) 

Es gibt eine ähnliche Position zu diesem Python Error The _posixsubprocess module is not being used jedoch die Antwort ein Link in den Kommentaren, die tot ist. Irgendwelche Ideen für mein Problem?

setup.py:

#!/usr/bin/python 

import os 
import sys 
from distutils.core import setup, Extension 


def main(): 
    if sys.version_info[0] != 2: 
     sys.stderr.write('This backport is for Python 2.x only.\n') 
     sys.exit(1) 

    ext = Extension('_posixsubprocess', ['_posixsubprocess.c'], 
        depends=['_posixsubprocess_helpers.c']) 
    if os.name == 'posix': 
     ext_modules = [ext] 
    else: 
     ext_modules = [] 

    setup(
     name='subprocess32', 
     version='3.2.7', 
     description='A backport of the subprocess module from Python 3.2/3.3 for use on 2.x.', 
     long_description=""" 
This is a backport of the subprocess standard library module from 
Python 3.2 & 3.3 for use on Python 2. 
It includes bugfixes and some new features. On POSIX systems it is 
guaranteed to be reliable when used in threaded applications. 
It includes timeout support from Python 3.3 but otherwise matches 
3.2's API. It has not been tested on Windows.""", 
     license='PSF license', 

     maintainer='Gregory P. Smith', 
     maintainer_email='[email protected]', 
     url='https://github.com/google/python-subprocess32', 

     ext_modules=ext_modules, 
     py_modules=['subprocess32'], 

     classifiers=[ 
      'Intended Audience :: Developers', 
      'Topic :: Software Development :: Libraries', 
      'Development Status :: 5 - Production/Stable', 
      'License :: OSI Approved :: Python Software Foundation License', 
      'Operating System :: POSIX', 
      'Operating System :: POSIX :: BSD', 
      'Operating System :: POSIX :: Linux', 
      'Operating System :: POSIX :: SunOS/Solaris', 
      'Programming Language :: Python :: 2.4', 
      'Programming Language :: Python :: 2.5', 
      'Programming Language :: Python :: 2.6', 
      'Programming Language :: Python :: 2.7', 
      'Programming Language :: Python :: 2 :: Only', 
      'Programming Language :: Python :: Implementation :: CPython', 
     ], 
    ) 


if __name__ == '__main__': 
    main() 

Antwort

0

Das Problem war, dass distutils den falschen Compiler zum Erstellen freigegebener Objekte verwendete (andere Objekte verwendeten den richtigen Compiler). Einstellen der unter LDSHARED Variablen während der Aufbauphase das Problem gelöst:

LDSHARED="$(TARGET_CC) -pthread -shared" 
0

Ich bin nicht sicher, welche Buildroot Version Sie verwenden, aber wenn es noch eine Version, die die GENTARGETS Makro verwendet und nicht über die python-package Infrastruktur, dann es muss eine wirklich, wirklich, wirklich alte Version sein. Bitte aktualisieren Sie zuerst, da viele, viele Korrekturen in den letzten Jahren in der Python-Unterstützung vorgenommen wurden.

+0

Um ehrlich zu sein, weiß ich nicht einmal, welche Version von buildroot es ist, ja, es ist alt, aber es Upgrade ist keine Option jetzt. Ich bin mir nicht sicher, ob das Problem damit oder subprocess32 auch ist. Diese große Veränderung würde viele Probleme auch anderswo haben, denke ich. – Paul

Verwandte Themen