8000 Issues using coreclr on Linux without Mono · Issue #801 · pythonnet/pythonnet · GitHub
[go: up one dir, main page]
Skip to content

Issues using coreclr on Linux without Mono #801

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rlordcardano opened this issue Jan 2, 2019 · 9 comments
Closed

Issues using coreclr on Linux without Mono #801

rlordcardano opened this issue Jan 2, 2019 · 9 comments

Comments

@rlordcardano
Copy link
rlordcardano commented Jan 2, 2019 •
edited
Loading

Environment

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
@rlordcardano rlordcardano mentioned this issue Jan 2, 2019
Closed
4 tasks
@den-run-ai
Copy link
Contributor

does npython.exe work for you? you can build it from the full solution in pythonnet repository.

@rlordcardano
Copy link
Author
rlordcardano commented Jan 3, 2019 •
edited
Loading

I confirm I can run dotnet nPython.dll that 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
Copy link
Contributor

PR #612 was supposed to add clr.so (clr.pyd) library that makes it possible to import clr pythonnet 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
Copy link
Author

@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
Copy link
Contributor

@rlordcardano yes, I should have been more specific - most likely nPython.exe is a .NET Framework or Mono build (depending on platform), while nPython.dll is a .NET Core build.

@rlordcardano
Copy link
Author
rlordcardano commented Jan 5, 2019 •
edited
Loading

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 --info gives 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
Copy link
Contributor
Cronan commented Apr 24, 2019

On CentOS 7 the locations are not very consistent:

  • /usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0
  • /opt/rh/rh-dotnet20/root/lib64/dotnet/shared/Microsoft.NETCore.App/2.0.7
  • /opt/rh/rh-dotnet21/root/usr/lib64/dotnet/shared/Microsoft.NETCore.App/2.1.2

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:

static const char* coreRootVar = "CORE_ROOT";
const char* clrFilesPath = getenv(coreRootVar);
if (clrFilesPath == NULL) {
    clrFilesPath = "/usr/share/dotnet/shared/Microsoft.NETCore.App/2.0.0";
}

if (!GetClrFilesAbsolutePath(pn_args->entry_path, clrFilesPath, &pn_args->clr_path))
{
    pn_args->error = "Unable to find clr path";
    return;
}

I chose CORE_ROOT because it's already used by corerun.exe.

This could be set in python or in the shell.

@filmor
Copy link
Member
filmor commented Apr 24, 2019

I'm looking into a pure Python solution using ctypes right now, there I'm parsing the output of the dotnet command to find the clr files.

@filmor
Copy link
Member
filmor commented Nov 8, 2019

Closed in favour of #984.

@filmor filmor closed this as completed Nov 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@filmor @Cronan @den-run-ai @rlordcardano
0