Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xplat native build with existing artifacts doesn't rebuild if only symbol stripping configuration has changed #20086

Open
dagood opened this issue Feb 2, 2017 · 7 comments
Labels
area-Infrastructure-libraries backlog-cleanup-candidate An inactive issue that has been marked for automated closure. enhancement Product code improvement that does NOT require public API changes/additions no-recent-activity
Milestone

Comments

@dagood
Copy link
Member

dagood commented Feb 2, 2017

CMake (or Make) doesn't rebuild the xplat binaries when -stripSymbols is set differently than the command that built what's in bin. Symbol stripping happens on build, so this means someone might run a "successful" build command that ends up with unexpected outputs in this very specific case. Repro:

  1. Perform the native CoreFX build without stripping symbols (default).
  2. Perform a native CoreFX build again with stripping enabled.
  3. The native build doesn't detect any changes, and doesn't rebuild, leaving you with unstripped binaries.

Workaround: clean the native artifacts to force a new build.

This was a known issue introduced with dotnet/corefx#15440.

/cc @ellismg

@wtgodbe
Copy link
Member

wtgodbe commented Dec 28, 2018

@dagood is this still an issue?

@dagood
Copy link
Member Author

dagood commented Jan 2, 2019

Yes, it still repros as of 70e7e11.

@ViktorHofer
Copy link
Member

I'm surprised that this still applies as our native build isn't incremental.

@dagood
Copy link
Member Author

dagood commented Jul 24, 2019

Huh, it always has been in my experience, and it is currently in Core-Setup at least.

(I haven't built CoreFX in a while though.)

@ViktorHofer
Copy link
Member

It's incremental now again in corefx as that was fixed recently. I'm not exactly sure what the action item here is (this is currently the oldest issue on our infra backlog). @dagood do you have suggestions?

@dagood
Copy link
Member Author

dagood commented Sep 3, 2019

If the issue is something that someone cares to fix, I would first verify the repro steps (although I really doubt it's been accidentally fixed), then fix it:

  1. Perform the native CoreFX build without stripping symbols (default).
  2. Perform a native CoreFX build again with stripping enabled.
  3. The native build doesn't detect any changes, and doesn't rebuild, leaving you with unstripped binaries.

I doubt it's a big issue if the dev is aware of it, or in general suspects the incremental build is causing problems (the workaround--a fresh build--is pretty typical), however it could be a very headache-inducing surprise.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@ViktorHofer ViktorHofer removed the untriaged New issue has not been triaged by the area owner label Jun 23, 2020
Copy link
Contributor

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels Dec 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Infrastructure-libraries backlog-cleanup-candidate An inactive issue that has been marked for automated closure. enhancement Product code improvement that does NOT require public API changes/additions no-recent-activity
Projects
None yet
Development

No branches or pull requests

5 participants