You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I get that, in the logic of the code, if a runtime is found, we don't want to display a whole bunch of clutter... But in the case where no runtime was found, it seems helpful to have some more details?
For instance, after digging, I found that the reason the runtime was not loading was:
(mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
Because Python is a universal binary, it is a bit unpredictable whether it is ran as arm64 or x86_64, and because .NET is available in the two flavours.... but the installed files don't seem to be marked with the architecture... that makes the whole thing a little tricky to debug.
The text was updated successfully, but these errors were encountered:
I'm very open to PRs that improve this. E.g. one could collect the exceptions and, when the search finally fails, include a summary of paths tried and the corresponding exception.
egaudrain
added a commit
to egaudrain/clr-loader
that referenced
this issue
Feb 27, 2025
When using:
If the loading fails, we merely get this error:
This is not very easy to debug because we don't know why the hostfxr might not be suitable.
The culprit is this piece of code, which just silences the error:
clr-loader/clr_loader/ffi/__init__.py
Lines 27 to 30 in cbe765c
I get that, in the logic of the code, if a runtime is found, we don't want to display a whole bunch of clutter... But in the case where no runtime was found, it seems helpful to have some more details?
For instance, after digging, I found that the reason the runtime was not loading was:
(mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
Because Python is a universal binary, it is a bit unpredictable whether it is ran as arm64 or x86_64, and because .NET is available in the two flavours.... but the installed files don't seem to be marked with the architecture... that makes the whole thing a little tricky to debug.
The text was updated successfully, but these errors were encountered: