Allow creating native library (static or shared)

[DemiMarie]

It should be possible to create a library (either static or dynamic) which exposes a C API, and which does not require callers to be aware that it is not written in C.

[jkotas]

Thank you for talking a look at the project. First class support for building libraries like this is definitely something we would like to support in CoreRT eventually. This involves providing a different version of startup code (src\Native\Bootstrap) and build scripts.

[jkotas]

#1498 is one of the problems that needs to be fixed to make this work.

[MihaMarkic]

This is a great proposition and would be of immense value. Hopefully it will be implemented.

[allquixotic]

Now that #1498 is fixed, what is left to make this happen? Can any of the core devs give kind of a roadmap for how this could be implemented? Are there any known chunks of work besides #1498 that are pending before this can be implemented in a fairly straightforward way?

[jkotas]

Here is what's needed to make this happen. For now, I would worry about RyuJIT codegen only for all of this.

• Create clone of the bootstrap code for dlls: Copy src\Native\Bootstrap\base to src\Native\Bootstrap\dll, rename bootstrapper to bootstrapperdll in the CMakeLists.txt, add add_subdirectory(bootstrapperdll) to src\Native\Bootstrap\CMakeLists.txt to add it to the build.

• Modify the bootstrap code for dlls to not have main method: Add add_definitions(-DCORERT_DLL) to src\Native\Bootstrap\dll\CMakeLists.txt and change src\Native\Bootstrap\main.cpp:

extern "C" void InitializeModules(void* osModule, void ** modules, int count, void ** pClasslibFunctions, int nClasslibFunctions);

#ifdef CORERT_DLL
#if defined(_WIN32)
#define wmain CoreRT_wmain
#else
#define main CoreRT_main
#endif
#endif

• Change build scripts under https://github.com/dotnet/corert/tree/master/src/BuildIntegration to not produce native .exe, but produce native .dll instead when a new NativeDll msbuild property is set

Now, you should be able to produce native .dll out of managed .exe. This native .dll should have CoreRT_wmain entrypoint that you can use to run it. You should be also able to export extern "C" entrypoints from it using NativeCallable attribute that you can call afer the CoreRT_wmain have finished.

The next step is get rid of the fake main method and polish this so that you can actually build the native .dll from managed library:

• Add command line switch to the ILC compiler like nativedll that will:
  • Supress looking for managed main method https://github.com/dotnet/corert/blob/master/src/ILCompiler/src/Program.cs#L286
  • Supress setting up or arguments and calling the managed main method in https://github.com/dotnet/corert/blob/master/src/ILCompiler.Compiler/src/IL/Stubs/StartupCode/StartupCodeMainMethod.cs#L71
  • Change the name of the __managed__Main method to just something like __managed_Startup with matching change in the boostrapperdll

@MichalStrehovsky Feel free to edit this post with anything else you can think of.

[tonerdo]

@jkotas I'd love to pick this up. I'd get started on it, right away

[jkotas]

@tonerdo It's yours. Thanks!

[bazzilic]

@tonerdo thanks for working on that! Been looking for a way to produce native libraries for the last week -- with no useful results. Hope you can put a prototype together soon, I'd be happy to test it!

[tonerdo]

@bazzilic Yeah I saw your message in gitter, was going to respond. I've started working on it and will let you know once I got something

[tonerdo]

@jkotas I notice that when I add

#ifdef CORERT_DLL
#if defined(_WIN32)
#define wmain CoreRT_wmain
#else
#define main CoreRT_main
#endif
#endif

and I try to build a shared library. I get the below error at the linking stage

Undefined symbols for architecture x86_64:
    "_main", referenced from:
        _PalGetModuleFileName in libRuntime.a(PalRedhawkUnix.cpp.o)
       (maybe you meant: __Z11CoreRT_mainiPPc)
  ld: symbol(s) not found for architecture x86_64

Typically this error is thrown by the linker when it doesn't find a main method when it's trying to build an executable but that should be suppressed when the switch to build a library is used. Any ideas?

[jkotas]

The problem is that PalGetModuleFileName is referencing the main method here:

corert/src/Native/Runtime/unix/PalRedhawkUnix.cpp

Line 1211 in 5856164

if (moduleBase == NULL)

I think that the fix for this should be to get rid of this code, and always require PalGetModuleFileName to take non-null argument (on Unix at least).

[tonerdo]

@jkotas so from my tests I realize the we still need CoreRT_main/main method to setup and tear down the runtime. What does this mean for a native library in the context of dlopen/LoadLibrary if those main functions have to be called before any managed function can be executed?

[jkotas]

Some of this is covered by "The next step is get rid of the fake main method and polish this" in my write up.

It is fine to have an option that initialize the runtime automatically when the library is loaded or when the first unmanaged method gets called. I would expect that this automatic options would be used by "simple" libraries. Folks complex programs will likely prefer the explicit initialization/shutdown methods.

It is not unusual for the "C" libraries to have initialize method that has to be called before anything else from the library is used.

[tonerdo]

@jkotas adding NativeCallable works alright on Unix and checking the resulting .dylib/.so file for exported functions shows the methods that have that attribute applied. For Windows however doing a dumpbin /EXPORTS on the generated native dll doesn't display any method including those that have the NativeCallable attribute applied.

This happens when using both Cdecl and StdCall calling conventions. The native dll is generated with:

LINK.EXE /DLL /OUT:NATIVELIB.DLL NATIVEOBJECT.OBJ @NATIVELIBS.LIB

Any ideas?

[jkotas]

On Windows, the methods have to be exported via .def file passed to the linker.

[tonerdo]

Aaah, forgot about that. Is there are provision in the compiler to automatically generate DEF files or is this something I need to add?

[jkotas]

For now, you need to add it. It may be possible to auto generate it in future, but it should be separate issue.

[tonerdo]

@nattress after a bit of google searches I've been able to come to the conclusion that the static library that contains that symbol wasn't compiled with position independent code in mind. I should mention that after pulling the latest master the problem symbol is no longer __GetNonGCStaticBase_S_P_CoreLib_System_AppContext but now __NewArr1___Array<Object>.

Full error output:

/usr/bin/ld: obj/Debug/netstandard2.0/native/cslib.o: relocation R_X86_64_PC32 against symbol `__NewArr1___Array<Object>' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

[jkotas]

@tonerdo Could you open github issues on the followup up work items for this that you are aware of, and link them to this issue?

[tonerdo]

@jkotas will do 👍

[sgf]

if could be create native lib,thats will be great !!!

[sergiy-k]

@sgf, did you see these sample/tests?
https://github.com/dotnet/corert/tree/master/tests/src/Simple/SharedLibrary
https://github.com/dotnet/corert/tree/master/tests/src/Simple/StaticLibrary

[MichalStrehovsky]

We now have small workitems tracking the remaining work here (see issues linking to this). Let's not have duplicate issues open.