This issue intended to discuss if we need to static link the native libraries to the runtime to serve in one executable scenario. The discussion triggered by the comments #33236 (review).

from @bartonjs
This change, overall, makes me sad. We intentionally stripped off the lib prefix as part of "these aren't general purpose libraries, don't look here". But if we need to, we need to, I guess.

from @jkotas
The alternative may be to statically link these libraries into the runtime for Android where it is causing problems. We are going to have this option for single file flavor of CoreCLR anyway, so doing it for Android as well (or even everywhere) should not be a big deal.

from @tarekgh
CC @akoeplinger Alexander Köplinger FTE and @marek-safar Marek Safar FTE to be aware of the suggestion.

from @marek-safar
statically link these libraries into the runtime

Xamarin.Android does not support this mode. I think this would be nice but we won't be in a position to deliver this for .net5. This looks more like .net6 enhancement because we would need to do native linking during publish phase (this depends on Android NDK, etc).

/cc @jonpryor

from @jkotas
For CoreCLR, the plan is to statically link the libraries as part of the dotnet/runtime build (see #32823). We are not planning to do native linking during publish phase.

from @marek-safar
That won't work for us. The thinking right now is to copy the dynamic libs which are used (during publish) and extend that to full static linking for Android as we plan to do for iOS (and wasm) during publish

from @jkotas
Just curious - why it does not work for you?

from @marek-safar
Primary because of size. If an app uses no crypto we should not link libSystem.Net.Security.Native and you can apply that to all native libs where System.IO.Compression.Native is probably the biggest one.

from @stephentoub
The moment someone brings in any managed HTTP implementation, client or server, it's going to end up requiring both of those. Presumably then the size concern would only be if they were using a platform-specific implementation (e.g. AndroidHttpHandler) where the platform provided all of that support?