pythonnet: CLR not working on 32 bit Linux

Environment

Pythonnet version: 2.5.1 and also 3.0.0-dev
Python version: 3.5.3, 2.7.13 and also 3.8.5 (from Debian repositories and also if compiled locally with --enable-shared)
MONO Versions: 6.10, 5.16 and also 5.20
Operating System: Linux (Debian 9 ‘stretch’ Live, i686)

Details

Pythonnet seems not to be working on a Linux 32-Bit environment (i686) at all. I tested it on a “Debian live” (USB) system in two different computers, using Python from the Debian repositories and also building python from source code, here are the results:

Using Python from the Debian repositories: The python execution crashes just doing import clr See attachment: mono_crash.4383a3eb2.0.zip, trace.txt
Building Python from source code (with --enable-shared):

It doesn’t crash, but clr throws an error when trying to load an assembly (“AttributeError: module ‘clr’ has no attribute ‘AddReference’”). This was reported in some places around internet, but I don’t have any clr module already installed which could cause a name collision. See output:

user@debian:~$ /opt/python/python3.5.3/bin/python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> dir(clr)
['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'facade']
>>> str(clr)
"<module 'clr' from '/opt/python/python3.5.3/lib/python3.5/site-packages/clr.cpython-35m-i386-linux-gnu.so'>"
>>> 
user@debian:~$ /opt/python/python3.5.3/bin/pip3 list
clang (11.0)
pip (9.0.1)
pycparser (2.20)
pythonnet (2.5.1)
setuptools (28.8.0)
wheel (0.35.1)

Notes

On a x64-System it works, using the same version of Debian, Pythonnet and Python.
If this is really a limitation of 32-Bit-Systems that cannot be fixed, it should be documented on the “readme”.

About this issue

Original URL
State: open
Created 4 years ago
Comments: 21 (14 by maintainers)

Most upvoted comments

@filmor A summary of bisecting is available here

The criteria that I used to decide if a commit was good or bad was by running the following bash script (which I named issue1210.sh) after each bisect iteration. If pytest passed then that commit was considered good.

#!/bin/bash
export LD_PRELOAD=/lib/i386-linux-gnu/libSegFault.so
export SEGFAULT_SIGNALS=all
export PYTHONUNBUFFERED=True
export BUILD_OPTS=""
export NUNIT_PATH="./packages/NUnit.ConsoleRunner.3.7.0/tools/nunit3-console.exe"
export RUN_TESTS="mono $NUNIT_PATH"
export EMBED_TESTS_PATH=""
export PERF_TESTS_PATH=""
source ~/py37env/bin/activate
python --version
pip --version
PY_LIBDIR=$(python -c 'import sysconfig; print(sysconfig.get_config_var("LIBDIR"))')
export LD_LIBRARY_PATH=$PY_LIBDIR:$LD_LIBRARY_PATH
pip install --upgrade setuptools
pip install --upgrade -r requirements.txt
pip uninstall pythonnet -y
coverage run setup.py install $BUILD_OPTS
python -m pytest

Please let me know if you’d like further information.

jborbely on Nov 4, 2020