Repository navigation
Issues using coreclr on Linux without Mono #801
Description
Environment
- Pythonnet version: PR Initial coreclr and build tooling #612
- Python version: 3.6.7
- Operating System: Ubuntu 18.04
Details
I was trying to test PR #612 for our use case (calling functionality implemented in .NET Standard 2.0 DLLs from Python 3.x). We currently manage to do this on Linux by using Mono and Pythonnet, but we are trying to avoid the dependency on Mono going forward.
Here I have included the dockerfile used to setup the required environment (Ubuntu 18.04 docker image, with .NET Core SDK, Python 3.6.7 and a clone of PR #612) so that one can reproduce what I'm seeing.
Subsequently, after starting the docker image, run:
cd pythonnet
python3 setup.py bdist_wheel --xplat
Subsequently, install the wheel that has been generated in the dist folder.
The error I get after this is:
>>>import clr
Failed to convert CLR files path to absolute path
Traceback (most recent call shown last):
File "<stdin>", line 1, in <module>
ImportError: Unable to find clr path
Activity
den-run-ai commentedon Jan 2, 2019
does npython.exe work for you? you can build it from the full solution in pythonnet repository.
rlordcardano commentedon Jan 3, 2019
I confirm I can run
dotnet nPython.dllthat is generated as part of the xplat build. Importing clr in there works.Looks like this route would work for a set of our use cases. I understand your comments in #96 better now and conclude that the other embedding route (not calling Python from a .NET app) does not work yet. Our other set of use cases would call C# DLLs within Jupyter notebooks - not sure nPython could be used there as an alternative Python kernel, could it?
den-run-ai commentedon Jan 3, 2019
PR #612 was supposed to add clr.so (clr.pyd) library that makes it possible to
import clrpythonnet from python without npython.exe.I asked you to check npython.exe to make sure that the problem comes from PR #612, which requires debugging now.
rlordcardano commentedon Jan 3, 2019
@denfromufa to be sure, nPython.exe does not work:
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/pythonnet/src/console/bin/'. Failed to run as a self-contained app. If this should be a framework-dependent app, add the /pythonnet/src/console/bin/nPython.runtimeconfig.json file specifying the appropriate framework.but I wouldn't expect it to as it targets .NET 4.0 (presumably it would work after installing Mono and the required runtime). The netcoreapp2.0 target framework produces nPython.dll, which does work.
den-run-ai commentedon Jan 3, 2019
@rlordcardano yes, I should have been more specific - most likely
nPython.exeis a .NET Framework or Mono build (depending on platform), whilenPython.dllis a .NET Core build.rlordcardano commentedon Jan 5, 2019
My two cents:
if (!GetClrFilesAbsolutePath(pn_args->entry_path, "/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0", &pn_args->clr_path))This is not always the location of the .NET Core runtime, e.g. on my system it's 2.1.5. There must be a way to find out programmatically what version of the runtime is installed. E.g.
dotnet --infogives the required information. This sounds like the easy part./src/runtime/pythonengine.cs: After setting that to the right path, it eventually crashes in line 168 (Runtime.Initialize).
/src/runtime/runtime.cs: Going further, the last point before it crashes is in calling Py_InitializeEx(0). There's not an issue with communicating with Python (call to Py_IsInitialized worked before). Error message "free(): invalid pointer".
Cronan commentedon Apr 24, 2019
On CentOS 7 the locations are not very consistent:
I'm not sure probing for the location will be very successful.
One way to solve it might be with an env variable, like so:
I chose CORE_ROOT because it's already used by corerun.exe.
This could be set in python or in the shell.
filmor commentedon Apr 24, 2019
I'm looking into a pure Python solution using ctypes right now, there I'm parsing the output of the
dotnetcommand to find the clr files.filmor commentedon Nov 8, 2019
Closed in favour of #984.