However, in Docker it's easier to understand what's going on, because the binaries/executables need to be linux binaries. It does definitely work if I use a docker container instead of WSL.
Theoretically, it should work, because the "environment" when you execute the binary should be the virtual machine. You installed VUnit inside a virtual machine, you mounted an external directory inside the virtual machine and you are asking a binary from that directory to access the home of the virtual machine. My feeling is that this use case goes beyond WSL's intended usage. Would be interested to hear any solutions and maybe my above explorations will help others. Is it for avoiding installing Python on Windows?Įven though its path is relative, I think, because it's installed in my home directory under WSL and not the "normal" Windows filesystem, that my Windows modelsim can't find the file. Overall, I wonder why are you using WSL, if the simulator is installed on Windows. Otherwise, VUnit might need to be patched for handling linux paths internally, but converting them before calling an external windows simulator. It would be interesting to investigate whether WSL includes any similar mechanism. In fact, it can be done implicitly and/or explicitly. In that case, there are mechanisms for converting paths from linux to windows format, and the other way round. That should avoid issues with path types.Ī similar problem exists with MSYS2/MINGW.
My first suggestion would be for you to try the Linux version of ModelSim instead. It seems that several of you are hitting issues when trying to use VUnit in a WSL1 or WSL2 terminal, along with a Windows version of ModelSim. Self.create_library(library.name, library.directory, mapped_libraries)įile "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-p圓.6.egg/vunit/sim_if/modelsim.py", line 219, in create_libraryįile "/usr/local/lib/python3.6/dist-packages/vunit_hdl-4.4.1rc0-p圓.6.egg/vunit/ostools.py", line 208, in consume_output
0 kommentar(er)
