I want to get started trying to develop a few simple applications with PyObjC. I installed PyObjC and the Xcode templates. I know that PyObjC itself works, since I've run this script successfully. When I tried to create a project from the Cocoa-Python Application template and ran it, I got this error:
Traceback (most recent call last):
File "main.py", line 10, in
import objc
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyObjC/objc/__init__.py", line 25, in
from _convenience import *
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyObjC/objc/_convenience.py", line 21, in
from itertools import imap
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so, 2): no suitable image found. Did find:
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload/itertools.so: mach-o, but wrong architecture
2010-02-08 19:40:09.280 TestApplication[3229:a0f] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '/Users/icktoofay/Desktop/TestApplication/main.m:44 main() PyRun_SimpleFile failed with file '/Users/icktoofay/Desktop/TestApplication/build/Debug/TestApplication.app/Contents/Resources/main.py'. See console for errors.'
When I tried opening a normal Python prompt and importing itertools, there was no error. I'm using Python 2.6.4 from MacPorts on Mac OS X 10.6 Snow Leopard.
I'd appreciate any help.
You have a 32-bit vs 64-bit problem. It appears you are using a Python 2.6 installed from MacPorts and apparently it was not a universal (32-bit/64-bit) build. Either your app is running as 64-bit and the Python is only 32-bit or the reverse. You can check by using file:
cd /opt/local/Library/Frameworks/Python.framework/Versions/2.6/
cd lib/python2.6/lib-dynload/
file itertools.so
itertools.so: Mach-O universal binary with 2 architectures
itertools.so (for architecture x86_64): Mach-O 64-bit bundle x86_64
itertools.so (for architecture i386): Mach-O bundle i386
The easiest fix is likely to re-install the MacPorts Python and the additional packages you installed like PyObjC:
sudo port selfupdate
sudo port -u install python26 +universal ...
EDIT: Since you report that the Python is 64-bit, the problem then is almost certainly due to a problem with the Xcode template setup for your Python PyObjC project. The startup code is probably loading the Apple-supplied Python interpreter which is universal. You can check by adding something like this prior to the import objc:
import sys
sys.stderr.write(sys.executable)
For MacPorts, it should be
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
I'm not familiar enough with the ins-and-outs of using the templates under Xcode to know what might need to be changed and I doubt that many people use them with a MacPorts Python, especially under 10.6.
Another thought, the Apple-suppied Python 2.6.1 comes with a version of PyObjC already installed. Perhaps using it would be simpler. Or don't use Xcode and use py2app or another solution to run it.
Related
Ubuntu Maverick w/Python 2.7:
I can't figure out what to do to resolve the following import error:
>>> import ssl
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/local/lib/python2.7/ssl.py", line 60, in <module>
import _ssl # if we can't import it, let the error propagate
ImportError: No module named _ssl
UPDATE:
I recompiled the source. I was unable to figure out how to add the --with-ssl option the answers below mention, instead I got this to work by editing the lines regarding SSL in /Modules/Setup.dist.
Unrelated to the original question, but because this is the first Google result... I hit this on Google AppEngine and had to add:
libraries:
- name: ssl
version: latest
to app.yaml per: https://cloud.google.com/appengine/docs/python/sockets/ssl_support
Please NOTE: This seems to work upto Python version 2.7.9 but not for 2.7.10 or 2.7.11.
Did you build the Python from source? If so, you need the --with-ssl option while building.
Since --with-ssl is not recognized anymore I just installed the libssl-dev.
For debian based systems:
sudo apt-get install libssl-dev
For CentOS and RHEL
sudo yum install openssl-devel
To restart the make first clean up by:
make clean
Then start again and execute the following commands one after the other:
./configure
make
make test
make install
For further information on OpenSSL visit the Ubuntu Help Page on OpenSSL.
If you built Python from source, this is just a matter of dependencies: since you miss OpenSSL lib installed, python silently fails installing the _ssl module. You can see it in the final report of the make command:
Python build finished, but the necessary bits to build these modules were not found:
_bsddb _sqlite3 _ssl
_tkinter bsddb185 dbm
dl gdbm imageop
sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.
Installing OpenSSL lib in any of the standard lib paths (/usr/lib, /usr/local/lib...) should do the trick. Anyway this is how I did :-)
I had exactly the same problem. I fixed it without rebuilding python, as follows:
Find another server with the same architecture (i386 or x86_64) and the same python version (example: 2.7.5). Yes, this is the hard part. You can try installing python from sources into another server if you can't find any server with the same python version.
In this another server, check if import ssl works. It should work.
If it works, then try to find the _ssl lilbrary as follows:
[root#myserver]# find / -iname _ssl.so
/usr/local/python27/lib/python2.7/lib-dynload/_ssl.so
Copy this file into the original server. Use the same destination folder:
/usr/local/python27/lib/python2.7/lib-dynload/
Double check owner and permissions:
[root#myserver]# chown root:root _ssl.so
[root#myserver]# chmod 755 _ssl.so
Now you should be able to import ssl.
This worked for me in a CentOS 6.3 x86_64 environment with python 2.7.3. Also I had python 2.6.6 installed, but with ssl working fine.
The underscore usually means a C module (i.e. DLL), and Python can't find it. Did you build python yourself? If so, you need to include SSL support.
I am writing this solution for those who are still facing such issue and cant find the solution.
in my case, I am using
shared hosting (Cpanel Access) Linux CentOS.
I was facing this issue
No module named '_ssl'
I tried for all possible solutions but as you know sometimes things don't work for you and in hosting you don't have access to fully root and run queries.
even my hosting provider did for me.. but NO GOOD RESULT.
so how I solved if you are using shared hosting and you have deployed your Django App using
Setup Python App
You only have to downgrade your Python Version, I downgraded from
Python 3.7.3
(As Python 3.7 does not have SSL module in it)
To
Python 3.6.8
through Setup Python App.
Hope it will be helpful for someone with the same issue,
Either install the supplementary packages for python-ssl using your package manager or
recompile Python using -with-ssl (requires OpenSSL headers/libs installed).
On Solaris 11, I had to modify setup.py to include /opt/csw/include/openssl in the SSL include search path.
Uwe
I'm using CXFreeze with PySide (QT). I get an error:
cx_Freeze: Python error in main script.
myscript.py line 33, in
File ExtensionLoader_Pyside_QtGUI.py, line 11, in
Import Error: DLL load failed: The specified module could not be found
When running a fresh install of Windows server 2008.
I'm running the frozen EXE package (with the folder). It seems to work on my own system and other systems. What might be the issue?
After reading, online, I tried to replace the Qt4Gui file, but this didn't solve the issue.
Python version is 2.7
Based on your Import Error: DLL load failed it is most likely an installation issue causing the missing DLL. To figure our exactly which DLL you are missing, use http://www.dependencywalker.com/ Run the .exe and open the .pyd file for File ExtensionLoader_Pyside_QtGUI.py and it will show you exactly which DLL's are missing and more importantly the locations where they should be. You can probably then track down the missing DLL online.
there are known issues with pyside 1.2.0 and cxFreeze. All should be fixed in development version (available on git repo). Please build the PySide from latest sources yourself or wait for PySide version 1.2.1. Build instructions are here [1].
[1] https://github.com/PySide/pyside-setup#building-pyside-on-a-windows-system
I used Py2exe instead of CXFreeze and it worked perfectly.
Also, apparently Python requires the MS Visual C++ Dependency Files:
http://www.microsoft.com/en-us/download/details.aspx?id=29
So any bundling needs that as well, if it's a fresh install. (Although I think they are now bundled with newer Windows versions.)
Other Notes:
In my experience, sometimes you should try CXFreeze, Py2EXE and PyInstaller quickly and see if one works best. As ideal as CXFreeze is re: cross platform, it just isn't going to happen perfectly.
Also, while I don't know if this was a factor, I set up a Windows 2000 Pro virtual machine and ran Py2exe on that. That was to ensure compatibility for all older Windows versions, and seemed to work well. (NOTE: Many things won't even run on Win2000 anymore so be careful that your other tools and libraries will run on it.)
Finally, be extra careful to match the bit level (32 vs 64) of all your libraries, and your Python install itself. If you have 32-bit python, ensure that your PySide, CXFreeze and any other libraries you use are 32-bit. (Or 64-bit if you're using 64-bit python.)
I've been trying to install PyGame with little success. I downloaded the
pygame-1.9.1release-python.org-32bit-py2.7-macosx10.3.dmg
version of PyGame from this link and installed it using the wizard, but when I typed import pygame into the IDLE I got the following message.
$ import pygame
Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
import pygame
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pygame/__init__.py", line 95, in <module>
from pygame.base import *
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pygame/base.so, 2): no suitable image found. Did find:
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pygame/base.so: no matching architecture in universal wrapper
What did I do wrong?
Also, what are the prerequisites for PyGame? I'm doing all this on a new computer and I've hardly downloaded anything.
I'm running OS X Version 10.8.2.
I know this thread is a little old, but thought I'd share my experience on this subject...
I'm using a 64-bit MacBook Pro running OS Mavericks and python 2.7.
Steps:
If you've installed a few different versions of pygame while trying to get the darn thing to import and work successfully, make sure you delete/uninstall all of these to get a fresh start. I did a simple search in the terminal to see where all of the various pygame folders where located:
In Terminal: sudo find / -iname "pygame"
The results show a list of all the pygame directories, these are the folders that you want to delete. Note, I created a new tab in terminal to do this so I can reference the directories from the search on the previous tab and easily copy each directory without having to do another search to remember where they are:
In Terminal: sudo rm -R -i path/pygame
Also note, you can take the -i out of the above code and it won't confirm the deletion of certain files, but BE REALLY CAREFUL when deleting full directories from the terminal.
Once your machine is clean of all previous pygame installations, make sure you have python 2.7 from python.org, NOT IDLE (default Mac Python Interpreter)! This is very important. I use PyCharm and it rocks! Also, choose the version that works on a 32-bit machine and 64-bit machine - this way you won't have issues with the pygame 32-bit installer on your 64-bit machine. I tried same installation process but with the 64-bit only python 2.7 installation and it didn't work. Link provided below:
Download 32/64-bit Python 2.7
Next, download the 32-bit pygame file for OS X 10.3 and beyond and run the mpkg file created from the dmg. Link provided below.
Download pygame 1.910 release for python 2.7
You should now have a working pygame installation in your python 2.7 package library. Enjoy.
Did you install python from python.org? Or use the one that came with OS X?
If you used the one supplied by Apple, you must download the one from python.org first, then install using that package. Or you can try the Lion-pygame package (the link is at the bottom of the Macintosh section of the download page), but it may be incompatible.
Did you download python 64-bit or python 32-bit?
This can cause major problems if you don't have the right one, if you have 64-bit you can download pygame 64-bit from http://www.lfd.uci.edu/~gohlke/pythonlibs/#pygame
I am attempting to build a python application with binary modules on OS X. I want to build versions for Snow Leopard and Leopard from Lion. I have XCode 4 installed with the 10.5 and 10.6 sdks and have been attempting to build using the MACOSX_DEPLOYMENT_TARGET flag set to 10.6. I receive an error from distutils complaining that python was built with a different deployment target.
I tried building a separate python binary with the deployment target set to 10.6 and then used virtualenv to try to build from that, but virtualenv expected a lib directory under the base env directory that was not there.
I am a total newb at developing on Mac and not even sure if what I want to do is possible. Am I going to have to break down and have someone still running Snow Leopard build my distributions?
I really appreciate any assistance.
The system Pythons shipped by Apple in OS X 10.7 are built for 10.7 only. The simplest solution is to download the most recent Python 2.7 or 3.2 64-bit/32-bit installer from python.org and use it since it is a universal binary that will run on either 10.6 or 10.7. If you are making an app bundle, you'll need to install a copy of py2app for it and any other 3rd-party packages like Distribute (aka easy_install) or pip.
I found the solution, go into your /System/Library/Frameworks/Python.framework/Versions/2.7/lib/distutils/sysconfig.py
Goto line 408 that says "raise DistutilsPlatformError" and add a '#' to comment out that line of code... This will "unleash the python"
You are basically telling python "don't worry its not 10.7, I know" there could be some crashes as a result but I think otherwise. My very complex python applicaiton now compiles on MacOSX 10.8 with no troubles and it seems to do the job, QA still has to test it though.
I'm configuring a new Developing Server that came with Windows 7 64bits.
It must have installed Trac with Subversion integration.
I install Subversion with VisualSVN 2.1.1, clients with TortoiseSVN 1.6.7 and AnkhSVN 2.1.7 for Visual Studio 2008 SP1 integration.
All works fine! my problem begun when going to Trac installation.
I install python 2.6 all fine.
Trac hasn't a x64 windows installer, so I installed it manually by compiling it with python console (C:\Python26\python.exe C:/TRAC/setup.py install).
After that, I can create TRAC projects normally, the Trac core is working fine. And so the problem begins, lets take a look at the Trac INSTALL file:
Requirements
To install Trac, the following software packages must be installed:
Python, version >= 2.3.
Subversion, version >= 1.0. (>= 1.1.xrecommended)
Subversion SWIG Python bindings (not PySVN).
PySQLite,version 1.x (for SQLite 2.x) or version 2.x (for SQLite 3.x)
Clearsilver, version >= 0.9.3 (0.9.14 recommended)
Python: OK
Subverion: OK
Subversion SWIG Python bindings (not PySVN):
Here I face the first issue, he asks me for 'cd' to the swig directory and run the 'configure' file, and the result is:
C:\swigwin-1.3.40> c:\python26\python.exe configure
File "configure", line 16
DUALCASE=1; export DUALCASE # for MKS sh
^
SyntaxError: invalid syntax
PySQLite, version 1.x (for SQLite 2.x) or version 2.x (for SQLite 3.x):
Don't need, as Python 2.6 comes with SQLLite
Clearsilver, version >= 0.9.3 (0.9.14 recommended):
Second issue, Clearsilver only has 32bit installer wich does not recognize python installation (as registry keys are in different places from 32 to 64 bits).
So I try to manually install it with python console. It returns me a error of the same kind as SWIG:
C:\clearsilver-0.10.5>C:\python26\python.exe ./configure
File "./configure", line 13
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
^
SyntaxError: invalid syntax
When I simulate a web server using the "TRACD" command, it runs fine when I disable svn support but when I try to open the web page it shows me a error regarding ClearSilver is not installed for generating the html content.
AND (for making me more happy) This TRAC will run over IIS7, I mustn't install Apache...
I'm nearly crazy with this issue... HELP!!!
Just export Register from [HKEY_LOCAL_MACHINE\SOFTWARE\Python] to [HKEY_CURRENT_USER\Software\Python].
It's happens because trac only see the [HKEY_CURRENT_USER\Software\Python] and you installed the python "For all users"
I would expect that Trac on Windows instructions should work on x64, even if they're 32-bit packages. Have you tried this and failed?
Subversion SWIG Python bindings:
configure is not meant to be run by Python; it's meant to be run with a POSIX sh, like Bash or ksh. However, if you read subversion/bindings/swig/INSTALL you'll find that the installation instructions for Windows do not use configure; instead, Visual Studio and gen-make.py are used.
Note that your bindings should match your installed Subversion.
Clearsilver:
Likewise, configure is meant for a sh, not Python. Clearsilver compilation instructions for Windows can be found in clearsilver/python/README.txt.
Looks like I'm not the only one trying to install Trac on Win 7 64-bit, only to see the install crash and burn.
One problem is the lack of installed registry entries for Python on Win x64, which I was able to find via a web search. The problem was identified months ago, but unfortunately no patch release has been made available.
I was almost ready to give up on Trac, but the information here has given me new hope. Thanks all!