Cocotb: Modelsim 32-bit invalid ELF header

[elgorwi]

Just updated my local cocotb installation from git and ran into an issue:

System:

• Centos 7 (64-bit)
• Intel Modelsim 2020.3 (32-bit)
• Installed anaconda 32-bit system as per instructions:
  https://github.com/cocotb/cocotb/wiki/Tier-2-Setup-Instructions
• Installed cocotb from git: pip install -v -e ./cocotb
• Cocotb version: 3a47227170d872e8bac1de9af3b5547f298d2bdb

Adder example ouput:
``$ make SIM=modelsim make results.xml make[1]: Entering directory/home/cocotb/examples/adder/tests'
set -o pipefail; MODULE=test_adder TESTCASE= TOPLEVEL="work.adder"
GPI_EXTRA= TOPLEVEL_LANG=verilog
/data/tools/intelFPGA_pro/20.3/modelsim_ase/linux/vsim -c -do sim_build/runsim.do 2>&1 | tee sim_build/sim.log
Reading pref.tcl

2020.3

do sim_build/runsim.do

Model Technology ModelSim - Intel FPGA Edition vmap 2020.3 Lib Mapping Utility 2020.07 Jul 22 2020

vmap -c

** Warning: vmap will not overwrite local modelsim.ini.

Model Technology ModelSim - Intel FPGA Edition vmap 2020.3 Lib Mapping Utility 2020.07 Jul 22 2020

vmap work sim_build/work

Modifying modelsim.ini

Model Technology ModelSim - Intel FPGA Edition vlog 2020.3 Compiler 2020.07 Jul 22 2020

Start time: 16:34:55 on Feb 05,2021

vlog -work work "+define+COCOTB_SIM" -sv -timescale 1ns/1ps -mfcu "+acc" /home/cocotb/examples/adder/tests/../hdl/adder.sv

-- Compiling module adder

Top level modules:

adder

End time: 16:34:55 on Feb 05,2021, Elapsed time: 0:00:00

Errors: 0, Warnings: 0

vsim -onfinish exit -pli "/home/cocotb/cocotb/libs/libcocotbvpi_modelsim.so" sim_build/work.adder

Start time: 16:34:55 on Feb 05,2021

Loading sv_std.std

Loading sim_build/work.adder

Loading /home/cocotb/cocotb/libs/libcocotbvpi_modelsim.so

-.--ns ERROR cocotb.gpi ..s/cocotb_utils.cpp:69 in utils_dyn_open Unable to open lib /home/.conda/envs/py3_32/lib/libpython3.7m.a: /home/.conda/envs/py3_32/lib/libpython3.7m.a: invalid ELF header

-.--ns INFO cocotb.gpi ../gpi/GpiCommon.cpp:105 in gpi_print_registered_impl VPI registered

End time: 16:34:55 on Feb 05,2021, Elapsed time: 0:00:00

Errors: 0, Warnings: 0

ERROR: results.xml was not written by the simulation!
make[1]: * [results.xml] Error 1
make[1]: Leaving directory `/home/cocotb/examples/adder/tests'
make: * [sim] Error 2
```

Also tried some older cocotb version (which gives the same error as in the log above):
331b879e39c587e94837f73eb05f73c04ec20c6e

This is the most recent cocotb version that runs adder example on modelsim without issues:
50418e54f000316257404134a57557ffb877e2c8

Any suggestions?
Thanks

[themperek]

It looks like cocotb-config --libpython returns libpython3.7m.a and it should libpython3.7m.so.
So potentially something here: https://github.com/cocotb/cocotb/blob/master/cocotb/_vendor/find_libpython/__init__.py

@ktbarrett

[ktbarrett]

This is a known issue in find_libpython (https://github.com/ktbarrett/find_libpython/issues/7). I haven't gotten around to testing RHEL systems yet (https://github.com/ktbarrett/find_libpython/issues/4). It turns out that code wasn't as bulletproof as we would like. I am thinking it probably shouldn't be vendored in so that it can always be as up to date as possible.

[themperek]

@ktbarrett Why not change ".a" to ".so" in those cases ?

[ktbarrett]

'.so's might not exist at the location. Its easiest to just filter those names out entirely. I dont think its a difficult problem, I just haven't gotten around to fixing and testing it yet.

[ktbarrett]

I replicated the issue, the "LDLIBRARY" config var is returning "libpython3.7m.a" and not the ".so" in the conda env =/ That's a pretty blatant misconfiguration, but I can add some safety checks to prevent that, just like is done for the "LIBRARY" config var.

[ktbarrett]

@elgorwi Could you try out this change in cocotb/_vendor/find_libpython/__init__.py? https://github.com/ktbarrett/find_libpython/pull/13/commits/95c37b3e2d1d838e5125e69a0df57ff8116ee235

I works on my Debian machine and a CentOS 7 container.

[ktbarrett]

I'll make it an action to vendor in the fix after it makes it into upstream.

[themperek]

Could you try out this change in cocotb/_vendor/find_libpython/__init__.py? ktbarrett/find_libpython@95c37b3

For me, it seems to work with this change.

[elgorwi]

Thanks for the patch @ktbarrett.
Just tried it and everything seems to be working on my system.