When I publish a "Hello World" app with PublishedTrimmed=true, the following native assemblies are published with my app:

These assemblies are always there, even if there are no calls to them. For "Hello World":

• libSystem.Net.Security.Native.so
• libSystem.Security.Cryptography.Native.OpenSsl.so

are not used. And if I set InvariantGlobalization=true in the app, then

• libSystem.Globalization.Native.so

is not used, and can be trimmed.

This would save 200-300 KB of size.

Larger savings could happen with libSystem.IO.Compression.Native.so. As it exists today, it contains the native code for Brotli compression and our "shim" APIs to call into zlib for Deflate compression. Typically, the Brotli code is unused, and could be trimmed. However, for CoreCLR apps, the Deflate shims are needed basically always because of it is needed to read portable PDB files for source/line information for stacktrace/exception messages.

If we were to implement this feature, we could split the Brotli and Deflate code into separate native assemblies, so the Brotli code could be trimmed. This would save another 800-900 KB.

Another potential idea here would be to add a Publish option to use the .a static libs at publish time. This would rely on a system linker, like PublishAot=true does. The advantage with this option is that native functions could be trimmed in these libraries. We wouldn't need to split the Compression.Native.so file. Instead, the Deflate code could remain while the Brotli code was trimmed.

cc @agocke @AaronRobinsonMSFT @sbomer