Tomasz Hemperek

Do you think we can close this? Any ideas?

> Should we be trying to ensure that all sim artifacts end up in `SIM_BUILD`? Then we can just rm -rf that. No need for simulator specific cleanup. Here somehow...

>ImportError: cannot import name 'simulator' from partially initialized module 'cocotb' (most likely due to a circular import) This can be solved with (in `site-packages/cocotb`) : ```cmd mv simulator.cpython-310-i386-linux-gnu.so simulator.cpython-310-x86_64-linux-gnu.so ```...

Actually this also seems to work ```cmd mv simulator.cpython-310-i386-linux-gnu.so simulator.so ``` @imphil We can remove lines bellow and this problem should go away (we just remove everything between `simulator` and...

It looks like enumeration/naming for loading/(compiling?) `.so` is base on system architecture and not the python binary. It looks like it is based no `sysconfig.get_config_var('EXT_SUFFIX')` see: https://peps.python.org/pep-3149/ In this case...

Some "interesting" "stuff": https://github.com/pypa/setuptools/pull/2723

So on windows (64bit) under coda we have: 32bit: `simulator.cp310-win32.pyd` 64bit: `simulator.cp39-win_amd64.pyd` And this works (proper `EXT_SUFFIX` based on python). Options: - on Linux skip everything between` simulator` and `.so`...

So there is a way to fix this: While compiling 32bit python add `CC="gcc -m32"`: So the command is : `env PYTHON_CONFIGURE_OPTS="--enable-shared" CC="gcc -m32" CFLAGS="-m32" LDFLAGS="-m32" pyenv install 3.x,y` I...

>I would be interested in seeing how Debian compiles their 32b python packages on a 64b multiarch system (it they provide python that way). Ubuntu 20.04 works with `CC="gcc -m32"`

Seems to work: http://themperek.github.io/cocotb/dev/bench/ Can be merged (need to make `gh-pages` branch).