I've been trying to learn nimlang because it seems like it has a lot of potential to integrate with python simply - but I'm a windows guy. The script I'm trying to compile is a simple one:
import zip/gzipfiles # Import zip package
block:
let vcf = newGzFileStream("test.txt.gz") # Open gzip file
var line: string # Declare line variable
# Loop over each line in the file
while not vcf.atEnd():
line = vcf.readLine()
echo line
Using a test file that I've gzipped called 'test.txt.gz':
this
is
gzipped
It compiles successfully on windows linux subsystem, and regular linux:
bub#bubs-surface-book-2:/mnt/c/Users/bubth/Development/nim$ nim c read_gzip.nim
Hint: used config file '/etc/nim.cfg' [Conf]
Hint: system [Processing]
Hint: read_gzip [Processing]
Hint: gzipfiles [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: algorithm [Processing]
Hint: times [Processing]
Hint: posix [Processing]
Hint: ospaths [Processing]
Hint: zlib [Processing]
Hint: streams [Processing]
CC: read_gzip
Hint: [Link]
Hint: operation successful (22504 lines compiled; 0.634 sec total; 35.035MiB peakmem; Debug Build) [SuccessX]
bub#bubs-surface-book-2:/mnt/c/Users/bubth/Development/nim$ ./read_gzip
asdf
1234
test
this
works
bub#bubs-surface-book-2:/mnt/c/Users/bubth/Development/nim$
But on windows, it compiles but then doesn't know how to use the zlib dll:
PS C:\Users\bubth\Development\nim> nim c .\read_gzip.nim
Hint: used config file 'C:\Users\bubth\scoop\apps\nim\current\config\nim.cfg' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: read_gzip [Processing]
Hint: gzipfiles [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
Hint: algorithm [Processing]
Hint: unicode [Processing]
Hint: pathnorm [Processing]
Hint: osseps [Processing]
Hint: winlean [Processing]
Hint: dynlib [Processing]
Hint: times [Processing]
Hint: options [Processing]
Hint: typetraits [Processing]
Hint: time_t [Processing]
Hint: zlib [Processing]
Hint: streams [Processing]
Hint: [Link]
Hint: operation successful (37181 lines compiled; 0.921 sec total; 46.852MiB peakmem; Debug Build) [SuccessX]
PS C:\Users\bubth\Development\nim> .\read_gzip.exe
could not load: zlib1.dll
PS C:\Users\bubth\Development\nim>
I've tried installing zlib via https://github.com/microsoft/vcpkg but even after walking through and successfully "linking" things, it's not finding the libraries. I swear I'm not stupid, but what am I missing? Is there some special way to get those packages onto windows in a way that nimble will recognize?
It looks like zip package assumes that you have the dll installed if you're on windows, and doesn't include it. To fix this, I had to manually download the correct .dll file and add it to my path, after which it compiled and ran just fine.
PS C:\Users\bubth\Development\vcpkg> .\vcpkg.exe install zlib:x64-windows
Computing installation plan...
The following packages are already installed:
zlib[core]:x64-windows
Package zlib:x64-windows is already installed
Total elapsed time: 618.1 us
The package zlib is compatible with built-in CMake targets:
find_package(ZLIB REQUIRED)
target_link_libraries(main PRIVATE ZLIB::ZLIB)
PS C:\Users\bubth\Development\vcpkg>
Added the vcpkg bin folder to my Path environment variable
C:\Users\bubth\Development\vcpkg\installed\x64-windows\bin
Recompiled and it ran:
PS C:\Users\bubth\Development\nim> nim c --run .\read_gzip.nim
Hint: used config file 'C:\Users\bubth\scoop\apps\nim\current\config\nim.cfg' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: read_gzip [Processing]
Hint: gzipfiles [Processing]
Hint: os [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
Hint: algorithm [Processing]
Hint: unicode [Processing]
Hint: pathnorm [Processing]
Hint: osseps [Processing]
Hint: winlean [Processing]
Hint: dynlib [Processing]
Hint: times [Processing]
Hint: options [Processing]
Hint: typetraits [Processing]
Hint: time_t [Processing]
Hint: zlib [Processing]
Hint: streams [Processing]
Hint: [Link]
Hint: operation successful (37182 lines compiled; 1.361 sec total; 58.07MiB peakmem; Debug Build) [SuccessX]
Hint: C:\Users\bubth\Development\nim\read_gzip.exe [Exec]
asdf
1234
test
this
works
PS C:\Users\bubth\Development\nim>
The source code for the zip nimble package, which I presume you are using, seems to be a wrapper around the zlib found at https://www.zlib.net. From there you have a few windows links which might contain the .dll file you need, particularly promising looks the zlib for windows website.
If you keep having problems with this module you could try creating an issue at the GitHub project, that README could really have a few links to binary downloads of the .dll you need.
Related
I have updated cmake and when i run catkin_make into the catkin_ws i got error in cmake even if got sudo apt update and sudo apt upgrade successful.
cd ~/catkin_ws
catkin_make
Below error is shown Cmake Error, cmake_check_build_system' failed.
Base path: /home/ubuntu/catkin_ws
Source space: /home/ubuntu/catkin_ws/src
Build space: /home/ubuntu/catkin_ws/build
Devel space: /home/ubuntu/catkin_ws/devel
Install space: /home/ubuntu/catkin_ws/install
####
#### Running command: "make cmake_check_build_system" in "/home/ubuntu/catkin_ws/build"
####
-- Using CATKIN_DEVEL_PREFIX: /home/ubuntu/catkin_ws/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/noetic
-- This workspace overlays: /opt/ros/noetic
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
-- Using Debian Python package layout
-- Using empy: /usr/lib/python3/dist-packages/em.py
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/ubuntu/catkin_ws/build/test_results
-- Forcing gtest/gmock from source, though one was otherwise available.
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found PythonInterp: /usr/bin/python3 (found version "3.8.10")
-- Using Python nosetests: /usr/bin/nosetests3
-- catkin 0.8.10
-- BUILD_SHARED_LIBS is on
Traceback (most recent call last):
File "/home/ubuntu/catkin_ws/build/catkin_generated/generate_cached_setup.py", line 22, in <module>
code = generate_environment_script('/home/ubuntu/catkin_ws/devel/env.sh')
File "/opt/ros/noetic/lib/python3/dist-packages/catkin/environment_cache.py", line 63, in generate_environment_script
env_after = ast.literal_eval(output.decode('utf8'))
File "/usr/lib/python3.8/ast.py", line 59, in literal_eval
node_or_string = parse(node_or_string, mode='eval')
File "/usr/lib/python3.8/ast.py", line 47, in parse
return compile(source, filename, mode, flags,
File "<unknown>", line 1
ROS_DISTRO was set to 'foxy' before. Please make sure that the environment does not mix paths from different distributions.
^
SyntaxError: invalid syntax
CMake Error at /opt/ros/noetic/share/catkin/cmake/safe_execute_process.cmake:11 (message):
execute_process(/usr/bin/python3
"/home/ubuntu/catkin_ws/build/catkin_generated/generate_cached_setup.py")
returned error code 1
Call Stack (most recent call first):
/opt/ros/noetic/share/catkin/cmake/all.cmake:208 (safe_execute_process)
/opt/ros/noetic/share/catkin/cmake/catkinConfig.cmake:20 (include)
CMakeLists.txt:58 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/ubuntu/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/ubuntu/catkin_ws/build/CMakeFiles/CMakeError.log".
make: *** [Makefile:3890: cmake_check_build_system] Error 1
Invoking "make cmake_check_build_system" failed
I couldn't solve? How can solve it?
Based on your comment you’re mixing ROS versions in your workspace. This isn’t valid in the same worksapce. You might have a system that uses both, but they should be built within different contexts; i.e. a directory shouldn’t contain both. It also should be noted that catkin isn’t the build system for ROS2(colcon is).
you have ROS_VERSION=2 and ROS_DISTRO=foxy, however, the rest refers to noetic. Try doing export ROS_VERSION=1 and export ROS_DISTRO=noetic.
I don't know how you are sourcing your workspace, but if you have that in your bashrc, I suggest removing it and sourcing it manually.
Because debian stretch have old package of gobject-introspection,i needed to update this.
But when i tryed to build, i got next message:
FAILED: gir/GLib-2.0.gir
/home/user/gobject-introspection-1.70.0/_build/tools/g-ir-scanner --output=gir/GLib-2.0.gir --no-libtool --quiet --reparse-validate --add-include-path /home/user/gobject-introspection-1.70.0/_build/gir --add-include-path /home/user/gobject-introspection-1.70.0/gir --identifier-prefix=G --symbol-prefix=g --symbol-prefix=glib --c-include=glib.h --namespace=GLib --nsversion=2.0 --library=glib-2.0 --library=gobject-2.0 --external-library --pkg=glib-2.0 --cflags-begin -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DGLIB_COMPILATION -D__G_I18N_LIB_H__ -DGETTEXT_PACKAGE=Dummy --cflags-end /usr/include/glib-2.0/gobject/glib-types.h /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h /usr/include/glib-2.0/glib-unix.h /usr/include/glib-2.0/glib/galloca.h /usr/include/glib-2.0/glib/garray.h /usr/include/glib-2.0/glib/gasyncqueue.h /usr/include/glib-2.0/glib/gatomic.h /usr/include/glib-2.0/glib/gbacktrace.h /usr/include/glib-2.0/glib/gbase64.h /usr/include/glib-2.0/glib/gbitlock.h /usr/include/glib-2.0/glib/gbookmarkfile.h /usr/include/glib-2.0/glib/gbytes.h /usr/include/glib-2.0/glib/gcharset.h /usr/include/glib-2.0/glib/gchecksum.h /usr/include/glib-2.0/glib/gconvert.h /usr/include/glib-2.0/glib/gdataset.h /usr/include/glib-2.0/glib/gdate.h /usr/include/glib-2.0/glib/gdatetime.h /usr/include/glib-2.0/glib/gdir.h /usr/include/glib-2.0/glib/genviron.h /usr/include/glib-2.0/glib/gerror.h /usr/include/glib-2.0/glib/gfileutils.h /usr/include/glib-2.0/glib/ggettext.h /usr/include/glib-2.0/glib/ghash.h /usr/include/glib-2.0/glib/ghmac.h /usr/include/glib-2.0/glib/ghook.h /usr/include/glib-2.0/glib/ghostutils.h /usr/include/glib-2.0/glib/gi18n-lib.h /usr/include/glib-2.0/glib/gi18n.h /usr/include/glib-2.0/glib/giochannel.h /usr/include/glib-2.0/glib/gkeyfile.h /usr/include/glib-2.0/glib/glib-typeof.h /usr/include/glib-2.0/glib/glist.h /usr/include/glib-2.0/glib/gmacros.h /usr/include/glib-2.0/glib/gmain.h /usr/include/glib-2.0/glib/gmappedfile.h /usr/include/glib-2.0/glib/gmarkup.h /usr/include/glib-2.0/glib/gmem.h /usr/include/glib-2.0/glib/gmessages.h /usr/include/glib-2.0/glib/gnode.h /usr/include/glib-2.0/glib/goption.h /usr/include/glib-2.0/glib/gpattern.h /usr/include/glib-2.0/glib/gpoll.h /usr/include/glib-2.0/glib/gprimes.h /usr/include/glib-2.0/glib/gprintf.h /usr/include/glib-2.0/glib/gqsort.h /usr/include/glib-2.0/glib/gquark.h /usr/include/glib-2.0/glib/gqueue.h /usr/include/glib-2.0/glib/grand.h /usr/include/glib-2.0/glib/grcbox.h /usr/include/glib-2.0/glib/grefcount.h /usr/include/glib-2.0/glib/grefstring.h /usr/include/glib-2.0/glib/gregex.h /usr/include/glib-2.0/glib/gscanner.h /usr/include/glib-2.0/glib/gsequence.h /usr/include/glib-2.0/glib/gshell.h /usr/include/glib-2.0/glib/gslice.h /usr/include/glib-2.0/glib/gslist.h /usr/include/glib-2.0/glib/gspawn.h /usr/include/glib-2.0/glib/gstdio.h /usr/include/glib-2.0/glib/gstrfuncs.h /usr/include/glib-2.0/glib/gstring.h /usr/include/glib-2.0/glib/gstringchunk.h /usr/include/glib-2.0/glib/gstrvbuilder.h /usr/include/glib-2.0/glib/gtestutils.h /usr/include/glib-2.0/glib/gthread.h /usr/include/glib-2.0/glib/gthreadpool.h /usr/include/glib-2.0/glib/gtimer.h /usr/include/glib-2.0/glib/gtimezone.h /usr/include/glib-2.0/glib/gtrashstack.h /usr/include/glib-2.0/glib/gtree.h /usr/include/glib-2.0/glib/gtypes.h /usr/include/glib-2.0/glib/gunicode.h /usr/include/glib-2.0/glib/guri.h /usr/include/glib-2.0/glib/gurifuncs.h /usr/include/glib-2.0/glib/gutils.h /usr/include/glib-2.0/glib/guuid.h /usr/include/glib-2.0/glib/gvariant.h /usr/include/glib-2.0/glib/gvarianttype.h /usr/include/glib-2.0/glib/gversion.h /usr/include/glib-2.0/glib/gversionmacros.h /usr/include/glib-2.0/glib/gwin32.h ../gir/glib-2.0.c
Traceback (most recent call last):
File "/home/user/gobject-introspection-1.70.0/_build/tools/g-ir-scanner", line 98, in <module>
from giscanner.scannermain import scanner_main
File "/home/user/gobject-introspection-1.70.0/_build/giscanner/scannermain.py", line 35, in <module>
from giscanner.ast import Include, Namespace
File "/home/user/gobject-introspection-1.70.0/_build/giscanner/ast.py", line 29, in <module>
from .sourcescanner import CTYPE_TYPEDEF, CSYMBOL_TYPE_TYPEDEF
File "/home/user/gobject-introspection-1.70.0/_build/giscanner/sourcescanner.py", line 34, in <module>
from giscanner._giscanner import SourceScanner as CSourceScanner
ImportError: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy
I know about required version glib >= 2.56.
I build it too and install from latest(2.70) source, but the error remains.
user#debian-stretch:/usr/lib/x86_64-linux-gnu$ cat /usr/lib/x86_64-linux-gnu/pkgconfig /gobject-2.0.pc
prefix=/usr
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
Name: GObject
Description: GLib Type, Object, Parameter and Signal Library
Version: 2.70.0
Requires: glib-2.0
Requires.private: libffi >= 3.0.0
Libs: -L${libdir} -lgobject-2.0
Cflags: -I${includedir}
user#debian-stretch:/usr/lib/x86_64-linux-gnu$ cat /usr/lib/x86_64-linux-gnu/pkgconfig /glib-2.0.pc
prefix=/usr
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
bindir=${prefix}/bin
glib_genmarshal=${bindir}/glib-genmarshal
gobject_query=${bindir}/gobject-query
glib_mkenums=${bindir}/glib-mkenums
Name: GLib
Description: C Utility Library
Version: 2.70.0
Requires.private: libpcre >= 8.31
Libs: -L${libdir} -lglib-2.0
Libs.private: -pthread -lm
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
Can you help with it trouble?
UPD
i read again this post and i had seen next thing:
default libglib2.0-0 package install some libs on to another path, in: /lib/x86_64-linux-gnu/
After that i tryed find it's on my instance, and got next out:
user#debian-stretch:~$ sudo find / -iname '*glib-2.0.*'
/usr/lib/x86_64-linux-gnu/libglib-2.0.so
/usr/lib/x86_64-linux-gnu/girepository-1.0/GLib-2.0.typelib
/usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc
/usr/lib/x86_64-linux-gnu/libglib-2.0.a
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0-gdb.py
/usr/share/gir-1.0/GLib-2.0.gir
/usr/share/aclocal/glib-2.0.m4
/usr/local/share/gdb/auto-load/usr/local/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0-gdb.py
/usr/local/share/aclocal/glib-2.0.m4
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.3
/lib/x86_64-linux-gnu/libglib-2.0.so.0
/home/user/glib-2.70.0/m4macros/glib-2.0.m4
/home/user/glib-2.70.0/_build/glib/libglib-2.0.so.0.7000.0.p
/home/user/glib-2.70.0/_build/glib/libglib-2.0.so
/home/user/glib-2.70.0/_build/glib/libglib-2.0.so.0.7000.0-gdb.py
/home/user/glib-2.70.0/_build/glib/libglib-2.0.so.0
/home/user/glib-2.70.0/_build/meson-private/glib-2.0.pc
/home/user/gobject-introspection-1.70.0/gir/glib-2.0.c
/home/user/gobject-introspection-1.70.0/subprojects/glib/m4macros/glib-2.0.m4
/home/user/packaging-glib/glib-2.70.0/usr/lib/x86_64-linux-gnu/libglib-2.0.so
/home/user/packaging-glib/glib-2.70.0/usr/lib/x86_64-linux-gnu/pkgconfig/glib-2.0.pc
/home/user/packaging-glib/glib-2.70.0/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7000.0
/home/user/packaging-glib/glib-2.70.0/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
/home/user/packaging-glib/glib-2.70.0/usr/share/aclocal/glib-2.0.m4
After remove this libs:
/lib/x86_64-linux-gnu/libglib-2.0.so.0.5000.3
/lib/x86_64-linux-gnu/libglib-2.0.so.0
building continue.
Definitely don't delete the GLib libraries in /lib. Since your package manager installed them there, other packages may expect to find them there, and so this may break your system down the line. (And since Debian Stretch is so old, with a GLib version of 2.50, it may even cause problems if you install GLib 2.70 systemwide.)
If you must install 2.70 systemwide, then I'd recommend building it with exactly the same configuration as the system version would. You can find the standard configuration options here and the options specific to GLib here. The options for gobject-introspection you can find in a similar place.
Even better, if you need to develop something using a GLib and gobject-introspection version that is not supported on your host system, would be to use some form of container technology. Either a runtime like Flatpak, or a "pet container" with a development environment, like Toolbox.
Steps to reproduce:
Create a file test.txt with content This is 中文 (i.e., UTF-8 encoded non-ASCII text).
Custom-compile python 3.5.2 on the Intel Edison.
Launch the custom-compiled python3 interpreter and issue the following piece of code:
with open('test.txt', 'r') as fh:
fh.readlines()
Actual behavior:
A UnicodeDecodeError exception is thrown. The file is opened as 'ASCII' instead of 'UTF-8' by default:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 8: ordinal not in range(128)
On a "regular" Linux system this problem is easily solved by setting a proper locale, see e.g. this post or that post. On the Intel Edison, however, I cannot set the LC_CTYPE since the default Yocto Linux distribution is missing locales (see e.g. this page).
I also tried to use a couple of other hacks like
import sys; sys.getfilesystemencoding = lambda: 'UTF-8'
import locale; locale.getpreferredencoding = lambda: 'utf-8'
And I tried setting the PYTHONIOENCODING=utf8 environment variable before starting the python interpreter.
However, none of this works. The only workaround is to specify the encoding explicitly as a command line parameter to the open command. This works for the above snippet, but it won't set the system-wide default for all packages I am using (that will implicitly open files as ASCII and may or may not offer me a way to override that default behavior).
What is the proper way to set the python interpreter default filesystem encoding? (Of course without installing unneeded system-wide locales.)
You can set the LC_ALL environment variable to alter the default:
$ python3 -c 'import locale; print(locale.getpreferredencoding())'
UTF-8
$ LC_ALL='.ASCII' python3 -c 'import locale; print(locale.getpreferredencoding())'
US-ASCII
I tested this both on OS X and CentOS 7.
As for your other attempts, here is why they don't work:
sys.getfilesystemencoding() applies to filenames only (e.g. os.listdir() and friends).
The io module doesn't actually use the locale.getpreferrredencoding() function, so altering the function on the module won't have an effect. A lightweight _bootlocale.py bootstrap module is used instead. More on that below.
PYTHONIOENCODING only applies to sys.stdin, sys.stdout and sys.stdstderr
If setting environment variables ultimately fails, you can still patch the _bootlocale module:
import _bootlocale
old = _bootlocale.getpreferredencoding # so you can restore
_bootlocale.getpreferredencoding = lambda *args: 'UTF-8'
This works for me (again on OS X and CentOS 7, tested with 3.6):
>>> import _bootlocale
>>> open('/tmp/test.txt', 'w').encoding # showing pre-patch setting
'UTF-8'
>>> old = _bootlocale.getpreferredencoding
>>> _bootlocale.getpreferredencoding = lambda *a: 'ASCII'
>>> open('/tmp/test.txt', 'w').encoding # gimped hook
'ASCII'
I know there are lots of similar questions on the website but I couldn't find an answer to my problem.
I'm wrapping C++ classes with Cython in order to use them with Python3. After building the external module with a setup.py, when I run the python program I got the following error:
from "name of.pyx file" import "name of the class to import"
Import error: /home/.../filename.so: undefined symbol: _ZTINSt8ios_base7failureB5cxx11E.
I'm on Ubuntu 16.04, I build the extensions from the terminal with the command line python3 setup.py build_ext --inplace, and then run the .py from the terminal or from Spyder in Anaconda (I got the error in both cases.)
From what I read the error might come from the cython compilation because i'm not linking some libraries. Is this true? If it is, could someone explain me how to do it?
I let you here my setup.py, in comments all the different setups I tried.
setup.py
from distutils.core import setup, Extension
from Cython.Build import cythonize
import numpy
#setup(ext_modules = cythonize(
#"pycoralv1.pyx", # our Cython source
#sources=["coralv1cpp.cpp"], # additional source file(s)
#language="c++", # generate C++ code
#))
#setup(ext_modules = cythonize(Extension(
# "pyCoralv1", # the extension name
# sources=["pyCoralv1.pyx", "Coralv1cpp.cpp"], # the Cython source and
# additional C++ source files
# language="c++", # generate and compile C++ code
# )))
#setup(
# name = "testcoral",
# ext_modules = cythonize('*.pyx'),
#)
ext_modules = [
Extension(
"pyCoralv1",
sources=["pyCoralv1.pyx", "Coralv1cpp.cpp"],
extra_compile_args=['-fopenmp',"-fPIC"],
extra_link_args=['-fopenmp',"-I", "/usr/include/glib-2.0", "-l", "glib-2.0", "-I", "/usr/lib/x86_64-linux-gnu/glib-2.0/include"],
language="c++",
)
]
for e in ext_modules:
e.pyrex_directives = {"boundscheck": False}
setup(
name='Coral library',
ext_modules=cythonize(ext_modules),
include_dirs = [numpy.get_include()]
)
The problem was solved after installing libgcc in anaconda: conda install libgcc, there was a missing library.
I'm making a program using Python2.7 and Kivy1.9.2-dev, and trying to package it with PyInstaller-3.0 for different systems as a single executable.
The systems I'm trying to package it for are these:
64-bit Linux Mint 17.3
32-bit Linux Mint 17 (also tried while upgrading to 17.1 and 17.3)
32-bit Windows XP SP3
Raspbian (Raspberry Pi)
On all these systems the program is working well when just run with Python, uncompiled. (so, all Kivy dependencies are fine, too).
However, out of the executables made with PyInstaller, only the one made on 64-bit Linux works as one file. The Windows and Raspbian executables mostly work (I'll write about it later), but the one made on 32-bit Linux still doesn't run. It gives the following error when run (I tried running it on both 32 and 64-bit Linux):
Traceback (most recent call last):
File "<string>", line 11, in <module>
File "/media/Data/Programming/Python/installers/PyInstaller-3.0/PyInstaller/loader/pyimod03_importers.py", line 363, in load_module
exec(bytecode, module.__dict__)
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 48, in <module>
File "/usr/local/lib/python2.7/dist-packages/pkg_resources/extern/__init__.py", line 60, in load_module
ImportError: The 'six' package is required; normally this is bundled with this package so if you get this warning, consult the packager of your distribution.
pyi_rth_pkgres returned -1
Here's what I'm confused about:
Inside my "/usr/local/lib/python2.7/dist-packages/" there is no "pkg_resources" folder, but the above indicates that it, apparently, is there... It even reads the files there successfully. Is it something that gets created just when the executable starts?
I don't specifically use "six" for anything, before this error I didn't even know it existed.
"Six" IS installed on my system, as confirmed by the Package Manager and by Pip. It's located in "/usr/local/lib/python2.7/dist-packages/". I guess PyInstaller can't find it for some reason (as, I believe, if everything is packaged correctly it doesn't have to be there on the system where the executable is run.)
So, my question is pretty typical, what may cause this problem for PyInstaller (just in case, I DID run the "setup.py install" for it), and how to get around/fix it?
Thanks!
PS: On a side note, I mentioned the problems with Windows and Raspbian executables. On Windows, the exe only runs when there is "zlib1.dll" present in the same folder (even if specifically packaged into the exe with PyInstaller, it doesn't work), and on Raspbian I only got the program working without using "--onefile" (with "--onefile", it seems PyInstaller doesn't package any Python binaries into the executable, like libpython.2.7.so, and maybe others too)
Well, adding 'six' into hidden packages, as Clement suggested, didn't work, but started a sequence of trial-and-error that finally led to a solution.
After the test with "hiddenimports" didn't work I tried just importing 'six' into my Python code. And the compiled executable no longer showed this error! However, it now said that the package named 'packaging' is required... Which I didn't have installed.
To put it short, starting from the initial problem, I did this:
Installed 'packaging' using 'pip':
sudo pip install packaging
Added these imports into my main Python code:
import six
import packaging
import packaging.version
import packaging.specifiers
(all the imports added were trial-and-error, done until the PyInstaller-made executable finally worked).
Seems a bit hack-y, as making the executable for a 64-bit Linux didn't require any of these imports, but at least it now works, and the executable size is basically unaffected.
For the following setup (anaconda):
PyInstaller: 3.2
Python: 3.5.2
Platform: Windows-10-10.0.10240-SP0
Numpy: 1.11.1
And the following mwe.py:
import numpy
print ("hello world")
I had to do the following to fix:
pip install packaging
Build with the following bat file (^ is the BAT line continuation):
pyinstaller --noconfirm ^
--hidden-import six ^
--hidden-import packaging ^
--hidden-import packaging.version ^
--hidden-import packaging.specifiers ^
--hidden-import packaging.requirements ^
mwe.py
I had a similar problem. Try to add "six" as well as "kivy" to the hidden_packages in your spec file. If it doesn't work, make sure that setuptools is installed in its 19.2 version. It seemed to be the problem for me on Windows. Hope it helps.