-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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.
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
Export monovm_create_delegate
#107778
base: main
Are you sure you want to change the base?
Export monovm_create_delegate
#107778
Conversation
It's public API and needs approval, though I'm not sure the process for hosting API.
What's the problem with |
Since I'm using the Mono runtime, it feels weird having to use an API with the
And as you can see in |
I don't think we should make it public. This is an implementation detail of mono's support for the coreclr hosting API. |
Mono uses CoreCLR names in number of places. For example, the Mono VM binary name is libcoreclr.so in some build configurations. It was a shortcut that we took during the initial integration of Mono into dotnet/runtime and we did not have a chance to go back to clean it up. We want the public surface of Mono and CoreCLR to be the same. |
Then why bother exposing Is it OK to use |
@lambdageek Do you happen to know why these got exposed? Are they still used? |
From #32136
I don't actually recall any tests that exercised these directly. Maybe we had something in mono/mono... |
I see
I also see some
What I don't see is any There's also some
The only And then, in the |
monovm_create_delegate
was missingMONO_API
, without it the symbol can't be found withdlsym
.For context,
MONO_API
was deemed not needed at the time of adding the API1. However, I'm interested in using this API directly instead of going throughcoreclr_create_delegate
for a Mono host implementation I'm working on.Footnotes
https://github.com/dotnet/runtime/pull/59962#discussion_r721646839 ↩