Self contained publish on linux includes .a files

[peterhuene]

@vitek-karas commented on Wed Feb 06 2019

Using relatively new 3.0 SDK

mkdir ca1
cd ca1
dotnet new console
dotnet publish --self-contained -r linux-x64

In the publish directory there are 6 .a files which don't seem to have any purpose. Basically for every native library (.so) coming from CoreFx, there's a corresponding .a as well:

-rwxrw-rw- 1 vitek vitek 2836614 Feb  5 04:05 System.IO.Compression.Native.a
-rwxrw-rw- 1 vitek vitek   27254 Feb  5 04:05 System.IO.Ports.Native.a
-rwxrw-rw- 1 vitek vitek  396432 Feb  5 04:05 System.Native.a
-rwxrw-rw- 1 vitek vitek   79868 Feb  5 04:05 System.Net.Http.Native.a
-rwxrw-rw- 1 vitek vitek   29400 Feb  5 04:05 System.Net.Security.Native.a
-rwxrw-rw- 1 vitek vitek  906184 Feb  5 04:05 System.Security.Cryptography.Native.OpenSsl.a

I don't think these files are needed for anything.
Per customer report this also reproes on MacOS, but I didn't verify.

---

@livarcocc commented on Wed Feb 06 2019

@peterhuene can you take a look?

---

@peterhuene commented on Wed Feb 06 2019

We should only be copying what's in the native assets directory, so if present it gets copied (hence why you get the .txt file too). Did something change in what gets packaged into Microsoft.NETCore.App?

I'll investigate.

---

@peterhuene commented on Wed Feb 06 2019

I can reproduce this on the current shipping 2.2.103 SDK.

It appears the runtime.$RID.microsoft.netcore.app packages (where $RID is not a Windows-based RID) does indeed contain the static library files in their native assets. As a result, they get treated like native assets like any other files and copied for the publish.

I think this is a core-setup issue. These files should not be packaged for Microsoft.NETCore.App packages on non-Windows platforms.

[dagood]

We can certainly filter these out in Core-Setup, but I think a better option is to have CoreFX stop putting the .a files in its transport packages. This keeps the change close to where the source lives.

Moving to CoreFX.

[dagood]

Issue moved to dotnet/corefx #35153 via ZenHub

[dagood]

Reopening: after discussion in https://github.com/dotnet/corefx/issues/35153, we will be filtering Microsoft.NETCore.App here. CoreRT uses the .a files from the CoreFX transport package, so they have to stay in the transport package.

[jkotas]

Filtering them when packaging NETCore.App will work ok fine for now.

Once the single-exe work proceeds to stage 5, we will need to keep bundling these into NETCore.App package (or a new NETCore.App sibling package). I think it is ok to delay solving this problem until we actually get there.

cc @swaroop-sridhar

[peterhuene]

@dagood now that we have runtime pack lists, it would be great to filter out .a, .md, or any other file that has nothing to do with running a self-contained application.

Also, is createdump a runtime dependency? If not, I don't think most users would want that in their published application.

[dagood]

Also, is createdump a runtime dependency? If not, I don't think most users would want that in their published application.

Yep, it is considered part of the runtime. It's launched when there's an unhandled exception and needs to be in the same dir as libcoreclr.so. /cc @mikem8361

[peterhuene]

I figured as much but I want to make sure. Thanks!

[mikem8361]

Yes, createdump has a dependency on “libmscordaccore.so” in the runtime directory. .