-
Notifications
You must be signed in to change notification settings - Fork 509
Generating native code with RyuJIT - linked native resource problem #6375
Comments
The problem is that the library is built for many platforms, including the platforms that require static linking.
The CoreRT compiler generates code for this static linking path and that's what causes the unresolved symbols during linking. |
@jkotas Should we maybe expose a command line option to stop treating @tokaplan The easiest way to make this go away (barring recompiling the NuGet with the using System;
using System.Runtime.InteropServices;
#if FIX
namespace System.Runtime.InteropServices
{
[AttributeUsage(AttributeTargets.Method)]
public sealed class NativeCallableAttribute : Attribute
{
public NativeCallableAttribute() { }
public CallingConvention CallingConvention;
public string EntryPoint;
}
}
#endif
internal class Program
{
[DllImport("__Internal")]
static extern void DoSomething();
#if FIX
[NativeCallable(EntryPoint = "DoSomething")]
static void DoSomethingImpl() { }
#endif
private static void Main(string[] args)
{
if (String.Empty.Length > 0)
DoSomething();
}
} This assumes that the |
...or since you're building CoreRT from source and not using the ILCompiler NuGet package, you can just comment out this: corert/src/Common/src/TypeSystem/Interop/IL/MarshalHelpers.cs Lines 109 to 111 in 52ec9ae
It's only for compatibility with Mono, but we don't rely on it for anything. |
We have the early bound import policy hardcoded in the compiler right now. Instead of having special option for just Or maybe we should have an option to force trim "bad" parts of the program/libraries (replace them with exception throwing). Kind of like inverse rd.xml. It would help us to deal with cases where the program has statically reachable part that you do not actually need, but that is causing problems. |
Ah yes. #2454. We should have a policy class that can decide on the way to do the import given a method as the parameter. Then we can pipe that through command line switches or RD.XML or any other mechanism. |
I don’t have control over the Grpc nugets unfortunately, so I’ll try the CoreRT side fix Michal has proposed. Thank you, I will let you know if that helps. |
So it appears that the fix has worked (at least in a sense that I'm not receiving that error any more). It finishes fine, but here's what I see now: As long as my Main() executes in the primary assembly, things work. However, when the code execution encounters a call to a different assembly - that call doesn't appear to get executed, but Main() continues to be executed successfully after that point. I lack fundamental understanding of how this whole thing works, can you please explain how this is possible and what I might be doing wrong? |
Never mind, I got confused. Native library is generally working (I have issues with reflection, but that would be a different issue). The corert-side fix suggested above worked for me. Regardless, thank you very much. |
PInvoke policy is tracked in #2454 |
is there an official fix? or I have to still create my own build of corert? how to publish a nuget in this case? |
@szhaomsft The linked issue was not fixed as you can see. You are welcomed to submit PR with a proposed fix. |
attempt a fix |
Following these instructions, I'm trying to generate a native executable from my .NET Core assembly which has a dependency on Grpc.Core nuget. I hit the following issue:
Turns out Grpc.Core's assembly uses a native DLL called grpc_csharp_ext.x64.dll. They invoke it via DllImport, but there's also some sort of static dependency in the metadata. This is how ILSpy shows it:
I've never seen this, but I'm guessing this is the sort of reference that -linkresource option creates as described here.
Regardless, the question is - what's the best course of action here? Should I be able to compile such assembly into native code? How do I proceed to fix this?
The text was updated successfully, but these errors were encountered: