Runtime: Change System.Native name to have lib prefix

[akoeplinger]

While working on bringing up the Android support I found out that on Android native libraries must conform to the naming convention of lib<name>.so otherwise the file won't be extracted from the .apk and you can't load them.

The current naming used for the PAL assemblies like System.Native.so won't work there.

Right now I just modified the build to include the lib prefix on Android but I'm wondering whether we could/should make this change for all Unix platforms?

/cc @jkotas @marek-safar @steveisok

[joperezr]

cc @ericstj since he might think of consequences that this may have with the runtime. AFAIK there shouldn't be much problem on doing this, as we don't expect people PInvoking into these directly from their code, so changing the name shouldn't be much of a problem but I may definitely be missing something.

[steveisok]

Assuming there isn't a big problem, I would prefer lib<name>.so

[ericstj]

So we've been telling folks not to depend on these as public surface because we wanted to reserve the right to make this type of change (also we change the name of exported methods release-by-release).

I did a quick scan of packages and found the following culprits that violate this:

• System.Security.Cryptography.OpenSsl -> depends on System.Security.Cryptography.Native.OpenSsl
  
  
  
  • This can be ignored, since it also ships inbox and the inbox version will win out over an old package.
  
  
• System.IO.Ports -> depends on System.IO.Ports.Native (OK since it also redists it), and System.Native (not OK)

So System.IO.Ports will break. This is the only one I found. That said it's a bug and we should fix it. I'd assert that any of our packages that are depending on these are bugs that should be fixed.

[jkotas]

Renaming System.Native -> libSystem.Native should not break anything. The DllImport probing will try with lib prefix. I would say to just do this.

We should still get the bad dependencies of non-inbox libraries on inbox shims fixed.

[ericstj]

Opened https://github.com/dotnet/runtime/issues/33130 to track fixing System.IO.Ports.

[marek-safar]

@ericstj could someone on your team do the work?

[ericstj]

@tarekgh does this sound like something you can pick up? I see you may have some experience from https://github.com/dotnet/corefx/pull/5403 and it's related to mono/xamarin bring up.

[tarekgh]

@ericstj I'll pick it up. I assume this is not super urgent as I want to flush some work items before doing that.

[jkotas]

@tarekgh When do you expect to get to this - days or weeks?

This is needed to enable Xamarin workloads in .NET 5. This work is a key .NET 5 deliverable and a long pole for .NET 5 that makes anything that contributes to it somewhat urgent.

[tarekgh]

should be done next week at most if it is not earlier.

[ericstj]

As Jan mentioned this might be easier than it looks. Simply renaming the lib(s) should still work without changing any DllImports due to the probing rules in CLR. We could even keep the directory structure the same and just update the output file name + docs.

[tarekgh]

@ericstj I will.

[ericstj]

Much thanks @am11 and @tarekgh