I'm using ubuntu and python 2.6
I found cx freeze already installed on my system (is it there a way to check if it's compatible with my Python version? )
however, i have a small pygame script (which import another module and some images) and i want to compile it;
i used this file as setup.py:
#!/usr/bin/python
from cx_Freeze import setup, Executable
setup(
name = 'Example',
version = '0.1',
description='hi',
executables = [Executable('/home/antonio/Python 26 save/opt/example.py')]
)
if i run the resulting executable, (through the terminal) i get this error:
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted
what should i do? I've searched but I found very few examples and I didn't see this error on google results
ps of course the program was running perfectly before using cx freeze
I have been getting a similar problem using python 2.7. I've found two causes of this segmentation fault in my own program, but I only have a solution to one of them.
Cause 1. Initialising fonts with no path, ie calling:
pygame.font.Font(None, font_size)
In this case, valgrind reports an invalid read at the address 0x0 in ??? in pygame.font.so
I would guess that this is because None is converted to a NULL pointer which something then assumes is a valid const char* string.
The fix for this problem is to always supply a valid path to a font.
Cause 2. Rendering unicode characters in fonts
pygame.font.Font("data/DejaVuSans.ttf", 14).render(u'\u2654')
valgrind reports an invalid read in PyString_AsString in libpython2.7.so.1.0
I'm sorry to say I don't have a solution for this.
PS:
I have just found another unicode related (but not pygame related) cause of problems with cxfreeze.
print u'\u2654'
In the python interpreter will print a king (chess piece), but when the script is compiled with cxfreeze, I get the following error (not a segmentation fault):
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2654' in position 0: ordinal not in range(128)
You also get this error in the python interpreter if you call:
print str(u'\u2654')
This seems to indicate that cxfreeze is assuming strings are always ascii strings.
Do you have any optimization options set when freezing the script? I'm not too sure if it does this, but it may be that it's incorrectly changing a variable to a reference. Again, I'm not an expert at cx_freeze, but my solution would be to update. Do you have the latest version (of cx_freeze)?
Did you google for your error (http://www.google.com/search?&q=Fatal%20Python%20error%3A%20%28pygame%20parachute%29%20Segmentation%20Fault) and check the various posts reporting the same error ?
E.g.
http://www.pyweek.org/d/2976/
http://osdir.com/ml/python.pygame/2001-12/msg00055.html
...
I have been getting the similar error and I think I have found the solution.
I am using
pygame.font.SysFont(None,25)
But instead of passing None argument you should use your system's fonts.
I have using windows machine so I have replaced none with any font that my system has. So I have replaced it to:
pygame.font.SysFont("comicsansms",25)
As you can see I have replaced None with comicsansms which is preinstalled fonts on windows PC
Hope it works!
Use
pygame.font.SysFont(FONT_NAME, FONT_SIZE).
Related
I am new with programming, so it is maybe harder for me to understand but I have the following issue:
I have a script that imports "eurostag.dll", which according to its manual, should work until Python 3.6. (but the manual is not updated, so it may work also with later updates, I assume).\ The issue is that I have Python 3.8. and when running the script I receive the following message:
"Failed to load EUROSTAG library (Could not find module 'D:\Eurostag\eustag_esg.dll' (or one of its dependencies). Try using the full path with constructor syntax.)"
I have tried to move the .dll library where the script is, but nothing changed. I tried also changing the directory with os.chdir, but the same message appears (with the same 'D:\Eurostag\eustag_esg.dll', so the directory was not changed.
Does anybody know if there is any workaround for this?
Thank you!
I'm trying to load pykd.pyd in order to be able to use Python during Windbg crash dump analysis. This does not work, as you can see here:
0:006> .load C:\Python27\Lib\site-packages\pykd.pyd
The call to LoadLibrary(C:\Python27\Lib\site-packages\pykd.pyd) failed,
Win32 error 0n126
"The specified module could not be found."
Please check your debugger configuration and/or network access.
For your information, I have started, opening Windbg (version x86) and opening a crash dump file, and I can confirm that the mentioned pykd.pyd file is present.
If I put the filename between double quotes, I get another error message, as you can see here:
0:006> .load "C:\Python27\Lib\site-packages\pykd.pyd"
The call to LoadLibrary(C:Python27Libsite-packagespykd.pyd) failed,
Win32 error 0n2
"The system cannot find the file specified."
Please check your debugger configuration and/or network access.
(It might be important to mention that both Win32 errors are different!)
Does anybody know what might cause this issue?
Thanks in advance
The Error Codes
The error message corresponds to the error codes. You can check that with the !error command:
0:000> !error 0n2
Error code: (Win32) 0x2 (2) - The system cannot find the file specified.
0:000> !error 0n126
Error code: (Win32) 0x7e (126) - The specified module could not be found.
So: nothing new here. WinDbg already told us.
The Quotation Marks
Since you are already debugging, let's debug this problem as well. Just know the right tool, which is Process Monitor.
Set up a filter like so:
"Process name", "contains", "windbg.exe", then "Include"
"Process name", "contains", "EngHost.exe", then "Include"
Now run the command
0:000> .load "c:\hello"
and you'll see that the quotes will mess up everything:
Now try
0:000> .load c:\hello
and you'll see that it searches in the right place:
Conclusion: .load is without quotation marks.
Loading PyKD
You are probably aware that there is 32 bit and 64 bit. And you can't load 32 bit DLLs in 64 bit processes nor 64 bit DLLs in 32 bit processes.
Same goes for debugging extensions: if you use 64 Bit WinDbg, you need 64 bit extensions. If you use 32 bit WinDbg, you need 32 bit extensions.
So first of all, check if your PyKD DLL (or .pyd here, which is actually .dll, just rename it) has the correct bitness (32 bit if I read that correctly).
Now, the 32 bit PyKD DLL will need a 32 bit installation of Python to run correctly. And likewise, 64 bit PyKD will need a 64 bit installation of Python.
Again you can help yourself with the right debugging tool. Process Monitor clearly shows that pykd.pyd is loaded successfully, but the dependency python38.dll (in my case, maybe Python 2.7 for you) is not:
For the following, I'm not 100% sure, but IMHO:
The PyKd DLL will try to find a Python system installation (as opposed to a virtual environment or venv).
That system installation must be in %PATH%
While you could have a 32 bit and 64 bit Python installation in the %PATH% variable, it will find one of them first. It might be the correct one or not.
Conclusion: put only one Python installation in %PATH% and use the correct bitness. Currently I only know this solution. Maybe the PyKD team posts an answer as well and explains how it can be done without modifying %PATH% all the time.
Don't load python package directly ( C:\Python27\Lib\site-packages\pykd.pyd ). It is a legacy unsupported way.
You need the special python bootstrapper for windbg:
https://githomelab.ru/pykd/pykd-ext
I am trying to run a simple python program, importing the paraview.simple module:
from paraview.simple import *
I get the following error:
Error: Could not import vtkCommonComputationalGeometry
I looked at similar posts on different fora and tried everything that was suggested there, but nothing worked for me. My Python path includes:
ParaView-5.7.0-MPI-Linux-Python2.7-64bit/bin/
ParaView-5.7.0-MPI-Linux-Python2.7-64bit/lib
ParaView-5.7.0-MPI-Linux-Python2.7-64bit/lib/python2.7/site-packages/
My LD_LIBRARY_PATH includes:
ParaView-5.7.0-MPI-Linux-Python2.7-64bit/lib/python2.7/site-packages/vtkmodules/
Does anybody know how to fix it?
Update:
I think there is an underline issue regarding the Unicode variant my python interpreter is using. I now get the following error:
Unicode error
ImportError: /home/nick/ParaView-5.7.0-MPI-Linux-Python2.7-64bit/lib/python2.7/site-packages/vtkmodules/vtkCommonCorePython.so: undefined symbol: PyUnicodeUCS2_DecodeUTF8
Does anybody know a fix?
You may want to use the pvpython program that is bundled with ParaView. It is basically a python interpreter but already setup with the correct paths.
If you want to use an external interpreter, you have to setup the PYTHONPATH environment variable to ParaView-5.7.0-MPI-Linux-Python2.7-64bit/lib/python2.7/site-packages/ and the LD_LIBRARY_PATH (on linux, PATH on windows) to ParaView-5.7.0-MPI-Linux-Python2.7-64bit/lib.
See also the ParaViewTutorial pdf from the download page (https://www.paraview.org/download/), at 3.1 Starting the Python Interpreter
I just successfully installed PyEphem using pip in a pyenv. However, on import I receive:
ImportError: /python2.7/site-packages/ephem/_libastro.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
In looking around I've seen it mentioned that some modules are built "against Python" in regards to Unicode and suggest recompiling. I'm quite new to Python and Ubuntu 14.04, and although I believe this is the answer to my issue, I do not know what recompiling means or how to do it.
The symbol PyUnicode_AsUTF8String(value) is used once in _libastro.c and is defined on my system in the file:
/usr/include/python2.7/unicodeobject.h
There it can be aliased one of two ways:
#ifndef Py_UNICODE_WIDE
# ...
# define PyUnicode_AsUTF8String PyUnicodeUCS2_AsUTF8String
# ...
#else
# ...
# define PyUnicode_AsUTF8String PyUnicodeUCS4_AsUTF8String
Your error message makes it sound as though your system Python is compiled to use 4-byte-wide Unicode strings (hence why the linker cannot find a UCS2 version of this function inside of it), but that the version of PyEphem that auto-compiled on your system when you ran pip install somehow got confused and unset Py_UNICODE_WIDE and thus generated C code that was expected a UCS2 symbol.
Do you have several compiled versions of Python on your system, where the Unicode setting of one version could accidentally be affecting how this compile for your system Python takes place?
So I downloaded source for Python3.4 and used VisualStudio 2010 to build a Python executable for my Windows7 machine. Ultimately, I want to use this to embed Python support in my application.
The first time I tried to execute my app, PyInitialise ends up aborting, and presents the error message:
"Py_Initialize: unable to load the file system codec"
So now I'm thinking, D'oh, you never installed your Python build after building it. After much googling, I find myself running msi.py. When I do, I see:
File "msi.py", line 934
raise ValueError, "Could not find "+srcdir+"/../"+pat
^
SyntaxError: invalid syntax
This looks to me like I'm trying to run pre-Python3.X code. But I'm so sure this MSI tool came with my Python3.4 source distribution. That said, I've been staring at this for so long things are starting to blend to a blur.
Any clues about where to look or what to try next?
Should I be worrying about MSI? Is there some other answer to my codec problem?