Uh oh!
There was an error while loading. Please reload this page.
Strip libmonosgen linked library - #53240
Conversation
It seems in the .symbols.nupkg package, instead of a stripped .dylib/so and companion .dwarf/.dbg, we've just been shipping unstripped libs. This commit largely duplicates the functions from eng/native/functions.cmake into an MSbuild proj, as our entire logic is already in MSbuild not CMake.
akoeplinger
left a comment
There was a problem hiding this comment.
This probably also fixes #45013, though we should check we don't impact XA/XI.
Uh oh!
There was an error while loading. Please reload this page.
akoeplinger
commented
Jun 2, 2021
What's the status of this PR? |
directhex
commented
Jun 2, 2021
I think it's fine, just running into flakiness in unrelated places in testing |
akoeplinger
commented
Jun 2, 2021
Retriggered the lanes just to be sure :) |
@directhex we would need to strip |
directhex
commented
Jun 7, 2021
@lateralusX how can i force a dynamic components build on... anything that isn't android? that's one platform i don't have the environment set up locally for |
directhex
commented
Jun 7, 2021
wait, docker, right. bleh |
directhex
commented
Jun 7, 2021
I hate docker |
directhex
commented
Jun 8, 2021
@lateralusX this is looking good locally |
lateralusX
commented
Jun 8, 2021
Sorry, just saw this, there is |
lateralusX
commented
Jun 8, 2021
What is the size of the stripped .so files? |
directhex
commented
Jun 8, 2021
|
It seems in all Mono .symbols.nupkg packages, instead of a stripped .dylib/so and companion .dwarf/.dbg, we've just been shipping unstripped libs (and shipping unstripped libs in the non-symbols packages too). This commit largely duplicates the functions from eng/native/functions.cmake into an MSbuild proj, as our entire install logic is already in MSbuild not CMake. Moving to the common CMake functions would be a much larger task.
This should reduce our install size, and better mirror the rest of dotnet's debug infra & behaviour.