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

[meta] Replace the custom linker steps with different solutions #17693

Open
rolfbjarne opened this issue Mar 3, 2023 · 0 comments
Open

[meta] Replace the custom linker steps with different solutions #17693

rolfbjarne opened this issue Mar 3, 2023 · 0 comments
Labels
enhancement The issue or pull request is an enhancement
Milestone

Comments

@rolfbjarne
Copy link
Member

rolfbjarne commented Mar 3, 2023

Note: this issue is incomplete, it still lacks a lot of detail.

We're using custom linker steps during our build in order to easily reuse pre-existing code we have for legacy Xamarin.iOS/Xamarin.Mac builds (mtouch/mmp).

  • The ILLinker team wants to remove support for custom linker steps, since it simplifies their code base and makes it easier for them to innovate.
  • The NativeAOT compiler trims code, but doesn't support custom linker steps. If we want to support NativeAOT without having to also run ILLinker first, we'll have to replace the custom linker steps with a different solution.

The custom linker steps are used for multiple purposes, and multiple different solutions will have to be implemented. The main idea is to add msbuild tasks that are executed before and after the trimmer (either ILLinker or NativeAOT).

  • We need to track of build times. A big advantage of the custom linker steps is that assemblies are only loaded once, during trimming. Adding other msbuild tasks that are executed before and after trimming means we'll have to load assemblies more than once, and this might slow down the build. We'll have monitor this and get numbers how bad it is for each step of the way.

(add list of all the custom linker steps)
(separate the removal of each step into it's own issue)

For app extensions, we'll need to generate an XML with everything we want rooted (ref: #19037). This way we'll hopefully be able to avoid this workaround: #19049

@rolfbjarne rolfbjarne added the enhancement The issue or pull request is an enhancement label Mar 3, 2023
@rolfbjarne rolfbjarne added this to the .NET 9 milestone Mar 3, 2023
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Sep 19, 2023
…ry projects. Fixes xamarin#19037.

ILLink doesn't handle library projects the way we need: the library is
automatically treated as a root assembly, with the entry point as the root.
This doesn't work, because library projects don't have an entry point.

In earlier versions of .NET (and Xamarin), we'd solved this by a custom linker
step that would manually root everything that needed to be rooted, but that
doesn't work anymore because we hit this sanity check in ILLink:

> ILLink : error IL1034: Root assembly 'MyExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have entry point.

Technically this happens because the library project is configured as a root
assembly, where the entry point is the root point (and in that regards the
sanity check is rather sane).

The best solution would be if we could just treat the library assembly as any
other assembly, and manually root it in our custom linker steps - but the
custom linker step we have for this kind of rooting will only iterate over
types in assemblies that are already marked somehow, and that's not
necessarily the case for app extension projects - the end result is that the
entire app extension assembly is linked away.

A close runner-up as the second best solution is to provide the API that needs
to be rooted as an xml file to the linker. This works, but we currently don't
have the infrastructure in the code to generate this xml file before running
the linker (it would be a rather major undertaking). This work is tentatively
scheduled for .NET 9 (xamarin#17693).

So I went for the third option: set RootMode="Library" for the library
assembly. I'm not sure exactly what that means ILLink will mark, but as long
as _anything_ is marked, our custom linker step will run. This seems like an
acceptable workaround until we can implement the previous solution.

Fixes xamarin#19037.
rolfbjarne added a commit that referenced this issue Sep 20, 2023
…ry projects. Fixes #19037. (#19049)

ILLink doesn't handle library projects the way we need: the library is
automatically treated as a root assembly, with the entry point as the root.
This doesn't work, because library projects don't have an entry point.

In earlier versions of .NET (and Xamarin), we'd solved this by a custom linker
step that would manually root everything that needed to be rooted, but that
doesn't work anymore because we hit this sanity check in ILLink:

> ILLink : error IL1034: Root assembly 'MyExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have entry point.

Technically this happens because the library project is configured as a root
assembly, where the entry point is the root point (and in that regards the
sanity check is rather sane).

The best solution would be if we could just treat the library assembly as any
other assembly, and manually root it in our custom linker steps - but the
custom linker step we have for this kind of rooting will only iterate over
types in assemblies that are already marked somehow, and that's not
necessarily the case for app extension projects - the end result is that the
entire app extension assembly is linked away.

A close runner-up as the second best solution is to provide the API that needs
to be rooted as an xml file to the linker. This works, but we currently don't
have the infrastructure in the code to generate this xml file before running
the linker (it would be a rather major undertaking). This work is tentatively
scheduled for .NET 9 (#17693).

So I went for the third option: set RootMode="Library" for the library
assembly. I'm not sure exactly what that means ILLink will mark, but as long
as _anything_ is marked, our custom linker step will run. This seems like an
acceptable workaround until we can implement the previous solution.

Fixes #19037.
@github-project-automation github-project-automation bot moved this to Technical Debt in .NET 9 Aug 27, 2024
@rolfbjarne rolfbjarne modified the milestones: .NET 9, .NET 10 Sep 13, 2024
@rolfbjarne rolfbjarne removed this from .NET 9 Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement The issue or pull request is an enhancement
Projects
None yet
Development

No branches or pull requests

1 participant