search

microsoft / dotnet

This repo is the official home of .NET on GitHub. It's a great starting point to find many .NET OSS projects from Microsoft and the community, including many that are part of the .NET Foundation.
https://devblogs.microsoft.com/dotnet/
MIT License
14.42k stars 2.21k forks source link

Cannot build UWP app in ARM64: exit code 1102 #1177

Open tipa opened 4 years ago

tipa commented 4 years ago

Building ARM64 packages works for most of my UWP apps, but one of them (the largest project) fails with this error:

2>  Processing application code
2>  Computing application closure and generating interop code
2>    Loading 158 modules...
2>    Generating code...
2>    Interop code generated.
2>  Generating serialization code
2>  Compiling interop code
2>  Generating System.Reflection.DispatchProxy proxy code.
2>  Cleaning up unreferenced code
2>  Generating native code
2>  Generating fixups for native code
2>C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\Microsoft.NetNative.targets(801,5): error : ILT0005: 'C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.7-rel-27913-00\tools\ARM64\ilc\tools\link\link.exe @"pathtoproj\obj\ARM64\Release\ilc\intermediate\linkargs.MyApp.rsp"' returned exit code 1102
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
A package has been successfully built for Release (x86).
A package has been successfully built for Release (x64).
A package has been successfully built for Release (ARM).
========== Package: 3 succeeded, 1 failed ===========
========== App Bundle: 1 succeeded, 1 failed ===========
dpaulino commented 4 years ago

I have this same issue with Nightingale. @tipa have you found any workarounds? Also, is your build failing on a CI pipeline or are you building locally on your machine? https://github.com/jenius-apps/nightingale-rest-api-client/issues/99

tipa commented 4 years ago

No I haven't found any workarounds, I gave up trying and don't build ARM64 variants for my apps any more.

dpaulino commented 4 years ago

@tipa I did some investigations and it looks like the issue is related to low memory. See this comment https://github.com/jenius-apps/nightingale-rest-api-client/issues/99#issuecomment-720960221

mfeingol commented 3 years ago

I've been having the same issue with my app, and I recently upgraded to 6.2.11 to see if that helps with this problem. Unfortunately, the build process still fails on ARM64:

3>C:\Users\mfeingol\.nuget\packages\microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\Microsoft.NetNative.targets(805,5): error : /c/Users/mfeingol/.nuget/packages/runtime.win10-arm64.microsoft.net.native.compiler/2.2.9-rel-29512-01/tools/ARM64/ilc/tools/link/link: missing operand after '��/'
3>C:\Users\mfeingol\.nuget\packages\microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\Microsoft.NetNative.targets(805,5): error : Try '/c/Users/mfeingol/.nuget/packages/runtime.win10-arm64.microsoft.net.native.compiler/2.2.9-rel-29512-01/tools/ARM64/ilc/tools/link/link --help' for more information.
3>C:\Users\mfeingol\.nuget\packages\microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\Microsoft.NetNative.targets(805,5): error : ILT0005: 'C:\Users\mfeingol\.nuget\packages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\ARM64\ilc\tools\link\link.exe @"C:\Operations\Build\Home\Sideroads\Source\Sideroads.Windows\obj\ARM64\Release\ilc\intermediate\linkargs.Sideroads.rsp"' returned exit code 1

Please let me know what sort of diagnostics might help.

tommcdon commented 3 years ago

Please share a structured msbuild log to dotnetnative@microsoft.com:

mfeingol commented 3 years ago

Thanks for following up, @tommcdon. Here's a log:

msbuild.binlog.zip

The file seems small, so I'm not sure it has the granularity you need. Let me know if I need to re-run with increased verbosity.

tapmatix commented 3 years ago

I ran into the exact same problem. Let me know if more logs could help, or if there is any workaround to try.

tommcdon commented 3 years ago

The error message in the msbuild log is:

LINK : the 32-bit linker (C:\Users\mfeingol\.nuget\packages\runtime.win10-arm64.microsoft.net.native.compiler\2.2.9-rel-29512-01\tools\ARM64\ilc\tools\link\link.exe) ran out of heap space and is going to restart linking with a 64-bit linker

In the 6.2.11 release, we added a compilation flag to disable symbols on ARM64. This saves memory and as a side-effect may unblock the build. To try it out, add <NoLinkerSymbols>true</NoLinkerSymbols> to the to the relevant ARM64 property groups in your csproj files.

It may also be possible to resolve the issue by reducing the input into the compiler. I’m not sure if we have shared these workarounds in the past, but these have historically been useful in helping to reduce the memory footprint to the compiler, which will also increase compilation speed:

Compiler flags

There are a wide range of flags available but here’s a couple that may help out: <ShortcutGenericAnalysis>true</ShortcutGenericAnalysis>- Can help stop runaway analysis of generic types and reduce overall generation requirements. <UseDotNetNativeSharedAssemblyFrameworkPackage>false</UseDotNetNativeSharedAssemblyFrameworkPackage> - Eliminates one of the linking boundaries the compiler has to fight with. I actually suspect turning this off will make things worse not better but whole program optimizers are hard to reason about but rebuilds are cheap enough to try. Runtime Directives There is a default.rd.xml file that provides "Runtime Directives" to the .NET Native compiler. The overall syntax of the file is also included in the reading above. The default config is the following, which may be leading to including "too much" metadata and code into the .NET native compiler engine: <Assembly Name="*Application*" Dynamic="Required All" /> Removing the directive but still have a working application may take some time iterating through a series of directives to try. There’s two approaches that have tradeoffs, so I’ll describe both and let you decide if either methodology suits you. Roughly here’s what the two workflows look like:

Start from nothing.

  1. Remove the special *Application* directive
  2. Build the app
  3. If the build fails, email us, else…
  4. Test the app and see if you hit any runtime errors
  5. If you do you’ll need to look at the error location and see if adding some directives can help then head back to (2).
  6. If you find no errors, you’re done! Hooray!

Start from everything

  1. Remove the special *Application* directive
  2. Get a list of the full set of dlls for your project, for example by inspecting here: obj[architecture]\Release\ilc\in
  3. For each dll, add a Dynamic directive. They’ll look like: <Assembly Name="ASSEMBLYNAMEWITHOUTEXTENTION" Dynamic="Required All"/>
  4. Comment out some subset of these libraries
  5. Build the app
  6. If the build fails again in RHBIND go to (4)
  7. Test the app and see if you hit any runtime errors
  8. If you do you’ll need to look at the error location and see if adding some directives can help then head back to (5)
  9. If you find no errors, you’re done! Hooray!

These articles provide some useful background info:

MagicAndre1981 commented 3 years ago

I get error code 1105. What does this mean?

I always get this when the source is on a network share, if the source is on local drive compiling works fine.