The implementation will be completely different, where the hook into CoreCLR
is in managed code.
We still need to initialize the framework_peer_release_lock mutex, so move
that code out of gc_enable_new_refcount.
We need to call coreclr_initialize/monovm_initialize at startup, so do that.
This is a partial implementation, in that we're not setting all the properties
that we should, and also the PINVOKE_OVERRIDE callback is not doing everything
it should either yet.
Ref: #10504.
* [runtime] Link the coreclr version of libxamarin with CoreCLR instead of Mono.
The diff might look a bit weird, because there's no changes specific to CoreCLR -
the difference is that we're in fact removing a special-case to link with Mono: we
used the DOTNET_$(rid)_LIBDIR variable to specify the directory where to find libcoreclr,
we now use DOTNET_CORECLR_$(rid)_LIBDIR when building for CoreCLR, but that's handled
by the default case, so no need to add any special casing. We still override DOTNET_osx-<arch>_LIBDIR
for MonoVM (no change needed for that).
* [runtime] Generate stubs for the mono embedding API when building for CoreCLR.
This makes libxamarin link successfully when building for CoreCLR.
* [runtime] Clean up public symbols. Fixes#5124.
Clean up public symbols, by:
* Symbols that don't need to be public (most of them), can be private.
* Prefix all public symbols with `xamarin_`.
* Add a test to ensure we don't introduce new public symbols.
* Use C symbols instead of mangled C++ symbols, since those are easier to
handle in the test.
This minimizes the chance of getting into a symbol clash with another native library.
Fixes https://github.com/xamarin/xamarin-macios/issues/5124.
* Some test fixes.
This makes exception marshaling work with Xamarin.Mac apps that use the system
mono (such as Visual Studio for Mac, and assuming at least a v5.12 system
mono).
https://github.com/xamarin/xamarin-macios/issues/4271
mono_set_pending_exception is a private mono symbol, which means we won't find
it when using the system mono (as a dynamic library). In that case, we'd
abort.
Instead try to call mono_raise_exception, and hope for the best. It will leak
somewhat, but that's still better than asserting.
This changes the generated wrapper function from:
```c
MONO_API void
mono_set_pending_exception (MonoException * exc)
{
if (mono_set_pending_exception_func == NULL)
xamarin_assertion_message ("Could not load mono_set_pending_exception\n");
return mono_set_pending_exception_func (exc);
}
```
to
```c
MONO_API void
mono_set_pending_exception (MonoException * exc)
{
if (mono_set_pending_exception_func == NULL)
return mono_raise_exception (exc);
return mono_set_pending_exception_func (exc);
}
```
Also this only applies to Xamarin.Mac apps that use the system mono (such as VSfM).
https://bugzilla.xamarin.com/show_bug.cgi?id=59979
The two functions mono_class_is_nullable and mono_class_get_nullable_param are
private mono symbols, which means we can't call them when using Xamarin.Mac
with libmono from a dynamic library.
Implement a fallback for this case, where we call a managed method when these
functions are not available (and restrict this workaround to Xamarin.Mac only,
since it's not needed for Xamarin.iOS).
* [runtime] Use printf on watchOS, NSLog doesn't shown up (by default).
* [runtime] Use a wrapper function for logging.
So that we can chose between printf and NSLog at runtime,
depending on where we're running.