Issues flowing debuginfo from corefx to final product #1016
Comments
|
The way the shared framework is put together is pretty unusual and I think it'd interfere with prebuilt detection: https://github.com/dotnet/core-setup/blob/1758b4706e9387d579bc00cbd7b7b64b07c48f1a/src/sharedFramework/sharedFramework.proj#L158. It should source only a local directory, so a clean/isolated build should be ok, but there are other NuGet things to contend with.... @omajid I wonder if it managed to pick up a package with a matching version from a NuGet cache on your machine? Can you check for this |
|
For now, fixing it by adding It would be nice to switch away from a restore call and assemble the shared framework in a more controlled way. Right now it depends on |
|
@dagood My nuget on this vm is empty: And for the sake of testing, I am modifying my build scripts to run |
|
There's also an HTTP cache at |
|
I actually added: And it didn't help :( |
|
I'd expect our offline builds to fail if there's some prebuilt required here... maybe it's sneaky enough to only get one if the build's online. 😕 That list of cleanup I'll kick off a couple builds locally with my usual online and offline steps to see if this repros in Docker isolation. (FWIW, I wouldn't expect the Core-Setup patch to be affecting this, because |
|
Since preview2, in online builds, the identity package is a prebuilt: In my tarball production build I have these in my <AnnotatedUsage Id="Microsoft.Private.CoreFx.NETCoreApp" Version="4.6.0-preview3.19128.7" File="src/core-setup/bin/obj/centos.7-x64.Release/Microsoft.NETCore.App/centos.7-x64/centos.7-x64/project.assets.json" IsDirectDependency="true" Project="src/core-setup/" SourceBuildPackageIdCreator="corefx MicrosoftPrivateCoreFxNETCoreAppPackageVersion/4.6.0-dev.19128.7" />
<AnnotatedUsage Id="Microsoft.Private.CoreFx.NETCoreApp" Version="4.6.0-preview3.19128.7" File="src/core-setup/bin/obj/centos.7-x64.Release/Microsoft.NETCore.App/project.assets.json" IsDirectDependency="true" Project="src/core-setup/" SourceBuildPackageIdCreator="corefx MicrosoftPrivateCoreFxNETCoreAppPackageVersion/4.6.0-dev.19128.7" />
...
<AnnotatedUsage Id="runtime.linux-x64.Microsoft.Private.CoreFx.NETCoreApp" Version="4.6.0-preview3.19128.7" File="src/core-setup/bin/obj/centos.7-x64.Release/Microsoft.NETCore.App/centos.7-x64/centos.7-x64/project.assets.json" Rid="linux-x64" Project="src/core-setup/" />The PVP sets the version, but since it matches official I guess it's up to resolution: Both "sources": {
"/work/bin/obj/x64/Release/blob-feed/packages/": {},
"https://api.nuget.org/v3/index.json": {},
"https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json": {},
"https://dotnet.myget.org/F/dotnet-core/api/v3/index.json": {},
"https://dotnet.myget.org/F/dotnet-corefxlab/api/v3/index.json": {},
"https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json": {},
"https://dotnetfeed.blob.core.windows.net/dotnet-coreclr/index.json": {},
"https://www.myget.org/F/nugetbuild/api/v3/index.json": {}
},The identity package isn't listed as a prebuilt, but it is, it's just omitted because it's ref-only. (#866) The runtime package does show up, in any case: I can confirm my offline build picks up the prebuilt identity package and prebuilt runtime package. So... this is known in the sense that the baseline includes it. @dseefeld @crummel do you know if this caused by any known issue? Will it show up in #885 at some point as something to drive down? |
|
It will show up at some point in work required to drive down prebuilts. The current issues that we have logged are just to drive down prebuilts that are direct dependencies. The assumption is that these will eliminate the most of the transitive dependencies as well, but in this case, I think we have more work to do. |
|
Ah... since the identity package is the direct dependency but it's ref-only, the runtime packages fly under the radar because those come from the identity package's About fixing, I think at some point I had a hypothesis that the search in the local dir and online are happening in parallel, and the online one might go faster and win. I'm not sure offhand how to verify this. A fix could be enforcing offline in this particular case. I don't have time to look at this further right now, but this is a more serious problem than most prebuilts IMO because corefx is being entirely ignored. |
|
@omajid It appears that the version of Microsoft.Private.CoreFx.NETCoreApp from PackageVersions.props is being overwritten from eng/Versions.props. The proposed fix is to swap these two lines: https://github.com/dotnet/core-setup/blob/328e1e262b67443fe47f091cf6bdde0b1b09bec4/dir.props#L55-L56 I'm testing that out now. |
|
That seems to have done the trick for me! Thanks! |
I am trying to build the source-build 3.0.0-preview3 tag (from source tarball) with extra debuginfo and the debuginfo is not showing up in the final built product. I don't know if changes are not flowing from corefx/coreclr to the final built sdk or if I am just not changing the right things.
source-build-info.txt
AFAIK, source-build disables stripping debuginfo. So everything built locally should contain debuginfo anyway. To be extra sure, I added this patch to core-setup to not strip anything: https://gist.github.com/omajid/f3ca14bed056b4a33a2ddf057b0a49b3
Once built, I scan over the files with this script: https://gist.github.com/omajid/766aef59857de9fc1eab173119143abc
It looks like
System.Net.Security.Native.sobuilt by corefx has the right debuginfo, but nothing else does. The version in core-setup is missing the debuginfo.The file modifiaction times of two examples from the list above are interesting:
The file built by corefx was modified today, while the copy in core-setup was modified in March?
The text was updated successfully, but these errors were encountered: