Closed woleda closed 4 years ago
I consider the xraylib
and xraylib_np
bindings to be completely separate, so it definitely makes sense to build one and not the other if build dependencies are missing.
Keep in mind that by default configure will try to enable as many language bindings as possible. Only if a particular binding was explicitly requested, and its dependencies were not available (like SWIG when using --enable-python
), will it choke. This is by design and don't think I will change this.
YES you have quite a few bindings to deal with here. Perhaps I had my head to far down the python hole. I leave this as a remark for other python3 'builders' like me, only setting env. var. like PYTHON=xxx and not using the specific --enble-python (since built by default), to make sure swig is available ;-). Thanks for comments and a nice toolkit! /Leif
No worries.
By the way have you tried installing my Debian Stretch packages?
yepp:
$ sudo apt-get install xraylib Reading package lists... Done Building dependency tree
Reading state information... Done xraylib is already the newest version (3.3.0-1+stretch). 0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
with python call resulting in:
$python import xraylib Traceback (most recent call last): File "/usr/lib/python3/dist-packages/xraylib.py", line 20, in swig_import_helper return importlib.import_module(mname) File "/usr/lib/python3.5/importlib/init.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "
", line 986, in _gcd_import File " ", line 969, in _find_and_load File " ", line 956, in _find_and_load_unlocked ImportError: No module named '_xraylib' During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "
", line 1, in File "/usr/lib/python3/dist-packages/xraylib.py", line 23, in _xraylib = swig_import_helper() File "/usr/lib/python3/dist-packages/xraylib.py", line 22, in swig_import_helper return importlib.import_module('_xraylib') File "/usr/lib/python3.5/importlib/init.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) ImportError: No module named '_xraylib'
and python3 in:
$python3
import xraylib Traceback (most recent call last): File "/usr/lib/python3/dist-packages/xraylib.py", line 20, in swig_import_helper return importlib.import_module(mname) File "/usr/lib/python3.5/importlib/init.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "
", line 986, in _gcd_import File " ", line 969, in _find_and_load File " ", line 956, in _find_and_load_unlocked ImportError: No module named '_xraylib' During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "
", line 1, in File "/usr/lib/python3/dist-packages/xraylib.py", line 23, in _xraylib = swig_import_helper() File "/usr/lib/python3/dist-packages/xraylib.py", line 22, in swig_import_helper return importlib.import_module('_xraylib') File "/usr/lib/python3.5/importlib/init.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) ImportError: No module named '_xraylib'
with an updated slocate db:
$locate xraylib /Public/Dc/Code/Python/Cadmium/Doc/xraylib-tutorial.pdf /etc/apt/sources.list.d/xraylib.list /usr/bin/xraylib /usr/include/xraylib /usr/include/xraylib/xraylib-auger.h /usr/include/xraylib/xraylib-crystal-diffraction.h /usr/include/xraylib/xraylib-defs.h /usr/include/xraylib/xraylib-lines.h /usr/include/xraylib/xraylib-nist-compounds.h /usr/include/xraylib/xraylib-parser.h /usr/include/xraylib/xraylib-radionuclides.h /usr/include/xraylib/xraylib-shells.h /usr/include/xraylib/xraylib.h /usr/include/xraylib/xraylib.mod /usr/lib/python2.7/dist-packages/_xraylib.so /usr/lib/python2.7/dist-packages/xraylib.py /usr/lib/python2.7/dist-packages/xraylib_np.so /usr/lib/python3/dist-packages/xraylib.py /usr/local/lib/perl5/site_perl/5.24.1/x86_64-linux-gnu-thread-multi/auto/xraylib /usr/share/xraylib /usr/share/doc/xraylib /usr/share/doc/xraylib/changelog.Debian.gz /usr/share/doc/xraylib/changelog.gz /usr/share/doc/xraylib/copyright /usr/share/xraylib/xraybanner.txt /usr/share/xraylib/xraydoc.txt /usr/share/xraylib/xrayfunc.txt /usr/share/xraylib/xrayhelp.txt /var/lib/dpkg/info/xraylib.list /var/lib/dpkg/info/xraylib.md5sums
and with a fresh system:
$ sudo apt-get upgrade Reading package lists... Done Building dependency tree
Reading state information... Done Calculating upgrade... Done The following packages have been kept back: cinnamon cinnamon-common cinnamon-dbg libasound2-plugins linux-headers-amd64 linux-image-amd64 mint-artwork 0 upgraded, 0 newly installed, 0 to remove and 7 not upgraded.
Never debugged this properly, but recalling having this nicely working under previous debian based Linux Mint/Linux Mint/Ubuntu. Perhaps i compiled the bindings. Don't remember. Sorry!
Thanks for the output. Looks like the python3 bindings were not properly packaged.
Can you try this with python2.7
? python
appears to map to python3
on your system.
Ohh, python2 is just fine. Sorry for that:
$python2 Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import xraylib import xraylib_np
This why you should always output proof - so that someone else can correct your mistakes :-) This is more in line with what I recall - python2 fine, python3 fail on LMDE 2 and 3 (stretch and jessie) using pre-packs. And the whole idea of not going $python -m xraylib was to get compiler AND python version. Don't know how that got lost!! Here the python3 build for the above:
$ python3 Python 3.5.3 (default, Sep 27 2018, 17:25:39) [GCC 6.3.0 20170516] on linux
Hmmmm!
Hold my horses. When compiling for python2 and python3 bindings using xraylib.__version__
3.99.2 with what I thought was a vanilla LMDE3 (debian stretch), I accidentally had a pip3 installed cython=0.29.13 in /usr/local/bin and a cython3 in /usr/bin !!! (yes, pip3 will play this trick on you). With default cython/cython3=0.25.2, compilation fails for both py2 and py3. in the latter case with a:
/usr/bin/cython3 -X boundscheck=False,wraparound=False,cdivision=True -I../include -o ./xraylib_np.c ./xraylib_np.pyx
Error compiling Cython file:
...
def XRayInit(): xrl.XRayInit()
cdef extern from "xraylib-deprecated-private.h": """ ^
xraylib_np.pyx:1507:4: Expected an identifier, found 'BEGIN_STRING'
with xraylib_np.pyx snipped being,
cdef extern from "xraylib-deprecated-private.h": """ XRL_GNUC_BEGIN_IGNORE_DEPRECATIONS """
Perhaps unimportant but, when passing compilation on this very binding (i.e. using cython=0.29.13) I do pick up a:
/usr/bin/cython3 -X boundscheck=False,wraparound=False,cdivision=True -I../include -o ./xraylib_np.c ./xraylib_np.pyx /usr/local/lib/python3.5/dist-packages/Cython/Compiler/Main.py:369: FutureWarning: Cython directive 'language_level' not set, using 2 for now (Py2). This will change in a later release! File: /usr/local/src/xraylib/python/xraylib_np.pyx tree = Parsing.p_module(s, pxd, full_module_name)
You switched to using the master branch I see.... it would appear from your troubles that the default Cython on Debian Stretch is too old for the upcoming 4.0.0 release: I will have to deactivate these bindings when doing my builds for this distro.
I have updated the Debian Stretch packages: they now include all files necessary to run the python3 bindings.
Thanks again for reporting this issue!
Great! Thanks for all your hard work!
Hi, this is not really an issues but when compiling for e.g. python3 the build process doesn't really complain about missing swig, rendering a only xraylib_np.la but not _xraylib.la nor xraylib.py. Maby configure should choke on this, given that xraylib_np != xraylib in terms of content?