build issue typemaps.x86_64.ll: error: Could not open input file: no such file or directory #8967

hansmbakker · 2024-05-20T12:14:15Z

Android application type

.NET Android (net7.0-android, net8.0-android, etc.)

Affected platform version

VS 2022 17.10 Preview 7

Description

When trying to debug my app, I sometimes get an issue like typemaps.x86_64.ll: error: Could not open input file: no such file or directory.
Another error I got was typemaps.armeabi-v7a.ll: error: Could not open input file: no such file or directory

This happens both in Visual Studio and on the command line using MSBuild.

The build error code is XA3006.

Steps to Reproduce

Not sure, but it is related to debugging on different devices having different processor architectures.

It happens e.g. when I try to deploy to my x86_64 emulator on my development machine after debugging via USB on a physical phone (which has an ARM processor).

Did you find any workaround?

No

Relevant log output

Please see the relevant tail of the logs below. The part before this (building the app) is common to all target devices and is working fine.

Skipping target "_LinkAssembliesNoShrink" because all output files are up-to-date with respect to the input files.
Skipping target "_GenerateJavaStubs" because all output files are up-to-date with respect to the input files.
Skipping target "_ManifestMerger" because all output files are up-to-date with respect to the input files.
Skipping target "_ConvertCustomView" because all output files are up-to-date with respect to the input files.
Skipping target "_AddStaticResources" because all output files are up-to-date with respect to the input files.
Skipping target "_GenerateEmptyAndroidRemapNativeCode" because all output files are up-to-date with respect to the input files.
Touching "obj\Debug
et8.0-android\stamp\_GeneratePackageManagerJava.stamp".
Skipping target "_GenerateAndroidAssetsDir" because all output files are up-to-date with respect to the input files.
Skipping target "_PrepareCreateBaseApk" because all output files are up-to-date with respect to the input files.
Skipping target "_CreateBaseApk" because all output files are up-to-date with respect to the input files.
Skipping target "_CompileJava" because all output files are up-to-date with respect to the input files.
[llc.EXE stderr] C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.95\tools\binutils\bin\llc.exe: error: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.95\tools\binutils\bin\llc.exe: typemaps.x86_64.ll: error: Could not open input file: no such file or directory
XA3006: Could not compile native assembly file: typemaps.x86_64.ll

stderr | C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.95\tools\binutils\bin\llc.exe: error: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.95\tools\binutils\bin\llc.exe: typemaps.x86_64.ll: error: Could not open input file: no such file or directory


Done building project "Anonymized.App.csproj" -- FAILED.
Build FAILED.
2>Deployment failed to Small_Phone_API_34.
2>Deploy failed
========== Build: 1 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
========== Build completed at 13:32 and took 11,768 seconds ==========
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========
========== Deploy completed at 13:32 and took 11,768 seconds ==========

The text was updated successfully, but these errors were encountered:

hansmbakker · 2024-05-20T12:15:15Z

@grendello let's discuss the build issue here.

I recorded a binlog and can share it confidentially (it contains client information).

hansmbakker · 2024-05-21T15:49:36Z

The logs are shared with @grendello's Microsoft account via OneDrive

grendello · 2024-05-22T15:07:51Z

@hansmbakker can you modify the C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.95\tools\Xamarin.Android.Common.targets file and apply the following diff:

diff --git a/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets b/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets
index 5d81e3f75..5c35118e6 100644
--- a/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets
+++ b/src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets
@@ -1443,7 +1443,7 @@ because xbuild doesn't support framework reference assemblies.
 <Target Name="_GenerateJavaStubs"
     DependsOnTargets="$(_GenerateJavaStubsDependsOnTargets);$(BeforeGenerateAndroidManifest)"
     Inputs="@(_AndroidMSBuildAllProjects);@(_ResolvedUserMonoAndroidAssemblies);$(_AndroidManifestAbs);$(_AndroidBuildPropertiesCache);@(AndroidEnvironment);@(LibraryEnvironments)"
-    Outputs="$(_AndroidStampDirectory)_GenerateJavaStubs.stamp">
+    Outputs="$(_AndroidStampDirectory)_GenerateJavaStubs.stamp;@(_TypeMapAssemblySource)">
 
   <PropertyGroup>
     <_ManifestOutput Condition=" '$(AndroidManifestMerger)' == 'legacy' ">$(IntermediateOutputPath)android\AndroidManifest.xml</_ManifestOutput>

And see if that fixes the issue?

hansmbakker · 2024-05-23T11:57:07Z

I'm off until Monday and will reply when I have a chance to do it

hansmbakker · 2024-05-24T17:51:21Z

@grendello I tried your change and it seems to help. I had to restart Visual Studio before it picked it up.

I updated the reproduction steps - it had something to do with switching debugging between devices that have different architectures.

Please note that xamarin/Xamarin.Forms#15719 and dotnet/maui#14531 (comment) seem to be related.

dezryth · 2024-05-25T01:16:50Z

Just popping in to say I'm getting this error too, but don't think I have anything helpful to add. Let me know if there is something I could provide to assist though.

dezryth · 2024-05-26T00:10:55Z

@grendello I tried the change as well and it worked for me. I did not have to restart Visual Studio.

crui3er · 2024-05-31T08:28:33Z

Thanks @grendello. It helped to me too.

Fixes: #8967 For some reason, sometimes the `typemap*.ll` files are sometimes removed from the `obj/` directory which leads to build errors similar to: typemaps.x86_64.ll: error: Could not open input file: no such file or directory Files are generated by the `GenerateJavaStubs` tasks, which is invoked by the `_GenerateJavaStubs` target. However, the target doesn't specify the `*.ll` files in its `Outputs` parameter and, therefore, whenever the files are removed but the `_GenerateJavaStubs.stamp` file is newer than the items/files specified in the target's `Inputs` parameter, the native assembly files aren't regenerated leading to the above error. To fix this, we need to add the `typemap*.ll` files to the target's `Outputs` set, thus forcing their regeneration should they be no longer where they are expected to be.

ur3an0 · 2024-06-09T23:07:14Z

gracias @grendello, también me funciono a mi esa solución

sabrigo · 2024-06-13T20:06:33Z

thank you... this solved the issue

bodeg · 2024-06-15T05:10:12Z

@grendello
you are a lifesaver. Thanks!

wdcossey · 2024-06-19T09:57:48Z

Just to confirm, it's [still] broken in Microsoft.Android.Sdk.Windows 34.0.113

The fix by @grendello still applies

C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools\Xamarin.Android.Common.targets

rhires · 2024-06-24T16:20:10Z

The fix shown in the diff worked for me.

dellis1972 · 2024-06-24T18:34:15Z

For all of those hitting this issue (and for whom the fix worked) it would be really nice to figure out what is deleting these files in the first place.

If you can a chance can you install the "Project System Tools" extension [1] and turn on the build logging and set it to capture All logs. Then try to repo the issue (without the fix). We would love to figure out what is causing the problem as the code we have should be working.

[1]https://github.com/dotnet/project-system-tools

kidmar · 2024-06-26T13:42:35Z

This happened to me after deleting bin and obj folders.
Restarting Visual Studio without changing anything solved the problem.

Orgbrat · 2024-06-28T15:27:17Z

This happened to me just switching between building Windows or iOS to an Android build and deploy to emulator.
Restarting Visual Studio without changing anything solved the problem.

dellis1972 · 2024-06-28T15:41:45Z

@Orgbrat if you can reliably reproduce it would be really handy to have all the binlog files for that process (see #8967 (comment)). Something in that process is causing files to be deleted.

Orgbrat · 2024-06-28T17:09:14Z

@dellis1972 I have installed project-system-tools as requested. I have to be away until after the holiday so I will try to reproduce and send you the logs with my details as soon as I am able. Although it does work now, I am curious if building one of the other platforms has anything to do with this issue.

hansmbakker · 2024-06-28T18:12:08Z

For me it seemed to happen when switching not between platforms per se (I did not try building for windows or iOS) but switching between targets devices.

I was switching between different android phones - two physical and one emulator. There were different processor architectures.

Fixes: #8967 For some reason, sometimes the `typemap*.ll` files are sometimes removed from the `obj/` directory which leads to build errors similar to: typemaps.x86_64.ll: error: Could not open input file: no such file or directory Files are generated by the `GenerateJavaStubs` tasks, which is invoked by the `_GenerateJavaStubs` target. However, the target doesn't specify the `*.ll` files in its `Outputs` parameter and, therefore, whenever the files are removed but the `_GenerateJavaStubs.stamp` file is newer than the items/files specified in the target's `Inputs` parameter, the native assembly files aren't regenerated leading to the above error. To fix this, we need to add the `typemap*.ll` files to the target's `Outputs` set, thus forcing their regeneration should they be no longer where they are expected to be.

pjt33 · 2024-07-10T08:51:26Z

For all of those hitting this issue (and for whom the fix worked) it would be really nice to figure out what is deleting these files in the first place.

I think it's not copying them in the first place. If I rebuild the basic template project then the only .ll files copied into obj/Debug/net8.0-android/android/ are .arm64-v8a.ll files. When I then try to debug on an x86_x64 emulator, it copies the .x86_x64.ll versions of all except typemaps. However, the fix doesn't work for me so maybe there are multiple issues at play here.

Edit: a workaround for me for development is to add <AndroidCreatePackagePerAbi>True</AndroidCreatePackagePerAbi> to the csproj, but I suspect that I won't want that when I come to compile a bundle for release.

dellis1972 · 2024-07-10T09:38:12Z

The reason only the x86.64.ll file is used when debugging is we detect the device abi which you are debugging agsinst and only build for that abi. This is different from release packages where we build for all the selected abis.

ziomek64 · 2024-07-16T10:39:28Z

For all of those hitting this issue (and for whom the fix worked) it would be really nice to figure out what is deleting these files in the first place.

I think it's not copying them in the first place. If I rebuild the basic template project then the only .ll files copied into obj/Debug/net8.0-android/android/ are .arm64-v8a.ll files. When I then try to debug on an x86_x64 emulator, it copies the .x86_x64.ll versions of all except typemaps. However, the fix doesn't work for me so maybe there are multiple issues at play here.

Edit: a workaround for me for development is to add <AndroidCreatePackagePerAbi>True</AndroidCreatePackagePerAbi> to the csproj, but I suspect that I won't want that when I come to compile a bundle for release.

This workaround worked for me

Fixes: #8967 For some reason, sometimes the `typemap*.ll` files are sometimes removed from the `obj/` directory which leads to build errors similar to: typemaps.x86_64.ll: error: Could not open input file: no such file or directory Files are generated by the `GenerateJavaStubs` tasks, which is invoked by the `_GenerateJavaStubs` target. However, the target doesn't specify the `*.ll` files in its `Outputs` parameter and, therefore, whenever the files are removed but the `_GenerateJavaStubs.stamp` file is newer than the items/files specified in the target's `Inputs` parameter, the native assembly files aren't regenerated leading to the above error. To fix this, we need to add the `typemap*.ll` files to the target's `Outputs` set, thus forcing their regeneration should they be no longer where they are expected to be.

jonathanpeppers · 2024-07-31T19:23:36Z

Does someone know the repro steps to cause this problem?

I thought that this would cause it inside Visual Studio:

F5 to an arm64 device
F5 to an x86_64 emulator

But that seems to work fine.

PredatH0r · 2024-08-01T14:02:05Z

For me it happened just now the first time after switching from the Android emulator (on x64) to a Samsung device (arm64) and then back again to the emulator.
The fix now allows me to run my app in the emulator again.

Fixes: dotnet#8967 Context: dotnet#9001 You can cause a build error in .NET 8 by doing: * Start an x86 or x86_64 emulator * `dotnet build -t:Run` * Close the emulator, attach an arm or arm64 device * `dotnet build -t:Run` Emits the error: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools\Xamarin.Android.Common.targets(2063,3): error XA3006: Could not compile native assembly file: typemaps.x86_64.ll stderr | C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools\binutils\bin\llc.exe: error: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools\binutils\bin\llc.exe: typemaps.x86_64.ll: error: Could not open input file: no such file or directory This works fine in Visual Studio, but not at the command-line. The underlying problem is due to `_GeneratePackageManagerJava` target running, while the `_GenerateJavaStubs` target *did not*: Skipping target "_GenerateJavaStubs" because all output files are up-to-date with respect to the input files. ... Input file "obj\Debug\net8.0-android\resolvedassemblies.hash" is newer than output file "obj\Debug\net8.0-android\stamp\_GeneratePackageManagerJava.stamp". These two targets should almost always run together, so we should ensure that they do. This problem also doesn't happen .NET 9, as both targets are invalidated for a different reason: Target Name=_LinkAssembliesNoShrink Project=UnnamedProject.csproj Building target "_LinkAssembliesNoShrink" completely. Output file "obj\Debug\android\assets\x86_64\UnnamedProject.dll" does not exist. Since, we build per-RID in .NET 9, `obj\Debug\android\assets\x86_64\UnnamedProject.dll` has an `x86_64` in the path, which is not present in the .NET 8 build. Reviewing the two sets of `Inputs`: <Target Name="_GenerateJavaStubs" ... Inputs="@(_AndroidMSBuildAllProjects);@(_ResolvedUserMonoAndroidAssemblies);$(_AndroidManifestAbs);$(_AndroidBuildPropertiesCache);@(AndroidEnvironment);@(LibraryEnvironments)" ... <Target Name="_GeneratePackageManagerJava" ... Inputs="@(_AndroidMSBuildAllProjects);$(_ResolvedUserAssembliesHashFile);$(MSBuildProjectFile);$(_AndroidBuildPropertiesCache);@(AndroidEnvironment);@(LibraryEnvironments)" Let's align them more closely by: * Track assembly changes in the exact same way: $(_ResolvedUserAssembliesHashFile);@(_ResolvedUserMonoAndroidAssemblies); This way if an assembly is added, removed, or timestamp changed: both targets are in sync. * Don't track `$(MSBuildProjectFile)`, this should already be in `@(_AndroidMSBuildAllProjects)`. With this change in place manually, I'm not able to reproduce the problem any longer. PR dotnet#9001 may also have fixed this issue, but it could cause targets to run on every incremental build -- a performance issue.

…ets (#9174) Fixes: #8967 Context: #9001 You can cause a build error in .NET 8 by doing: * Start an x86 or x86_64 emulator * `dotnet build -t:Run` * Close the emulator, attach an arm or arm64 device * `dotnet build -t:Run` Emits the error: Xamarin.Android.Common.targets(2063,3): error XA3006: Could not compile native assembly file: typemaps.x86_64.ll stderr | C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools\binutils\bin\llc.exe: error: C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools\binutils\bin\llc.exe: typemaps.x86_64.ll: error: Could not open input file: no such file or directory This works fine in Visual Studio, but not at the command-line. The underlying problem is due to `_GeneratePackageManagerJava` target running, while the `_GenerateJavaStubs` target *did not*: Skipping target "_GenerateJavaStubs" because all output files are up-to-date with respect to the input files. ... Input file "obj\Debug\net8.0-android\resolvedassemblies.hash" is newer than output file "obj\Debug\net8.0-android\stamp\_GeneratePackageManagerJava.stamp". These two targets should almost always run together, so we should ensure that they do. This problem also doesn't happen .NET 9, as both targets are invalidated for a different reason: Target Name=_LinkAssembliesNoShrink Project=UnnamedProject.csproj Building target "_LinkAssembliesNoShrink" completely. Output file "obj\Debug\android\assets\x86_64\UnnamedProject.dll" does not exist. Since, we build per-RID in .NET 9, `obj\Debug\android\assets\x86_64\UnnamedProject.dll` has an `x86_64` in the path, which is not present in the .NET 8 build. Reviewing the two sets of `Inputs`: <Target Name="_GenerateJavaStubs" ... Inputs="@(_AndroidMSBuildAllProjects);@(_ResolvedUserMonoAndroidAssemblies);$(_AndroidManifestAbs);$(_AndroidBuildPropertiesCache);@(AndroidEnvironment);@(LibraryEnvironments)" ... <Target Name="_GeneratePackageManagerJava" ... Inputs="@(_AndroidMSBuildAllProjects);$(_ResolvedUserAssembliesHashFile);$(MSBuildProjectFile);$(_AndroidBuildPropertiesCache);@(AndroidEnvironment);@(LibraryEnvironments)" Let's align them more closely by: * Track assembly changes in the exact same way: $(_ResolvedUserAssembliesHashFile);@(_ResolvedUserMonoAndroidAssemblies); This way if an assembly is added, removed, or timestamp changed: both targets are in sync. * Don't track `$(MSBuildProjectFile)`, this should already be in `@(_AndroidMSBuildAllProjects)`. With this change in place manually, I'm not able to reproduce the problem any longer. PR #9001 may also have fixed this issue, but it could cause targets to run on every incremental build -- a performance issue.

zijianhuang · 2024-09-03T10:25:27Z

@grendello has given a good answer about modifying file in tools\Xamarin.Android.Common.targets

The problem has come back to me upon VS 17.11.2, now go to the targets file in
C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.0.113\tools

Not sure if MS should fix this?

grendello · 2024-09-03T12:47:45Z

@zijianhuang it's fixed in #9174

hansmbakker added Area: App+Library Build Issues when building Library projects or Application projects. needs-triage Issues that need to be assigned. labels May 20, 2024

hansmbakker assigned dellis1972 and jonathanpeppers May 20, 2024

hansmbakker mentioned this issue May 20, 2024

Crash: [libc] Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) during app startup dotnet/runtime#106970

Open

grendello added need-info Issues that need more information from the author. and removed needs-triage Issues that need to be assigned. labels May 23, 2024

microsoft-github-policy-service bot added need-attention A xamarin-android contributor needs to review and removed need-info Issues that need more information from the author. labels May 23, 2024

grendello mentioned this issue Jun 4, 2024

Make sure _GenerateJavaStubs always generates native assembly files #9001

Closed

jonathanpeppers mentioned this issue Aug 6, 2024

[Xamarin.Android.Build.Tasks] fix Inputs for _Generate*Java* targets #9174

Merged

jonathanpeppers closed this as completed in #9174 Aug 6, 2024

github-actions bot locked and limited conversation to collaborators Oct 4, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

build issue typemaps.x86_64.ll: error: Could not open input file: no such file or directory #8967

build issue typemaps.x86_64.ll: error: Could not open input file: no such file or directory #8967

hansmbakker commented May 20, 2024 •

edited

Loading

hansmbakker commented May 20, 2024 •

edited

Loading

hansmbakker commented May 21, 2024

grendello commented May 22, 2024

hansmbakker commented May 23, 2024

hansmbakker commented May 24, 2024 •

edited

Loading

dezryth commented May 25, 2024

dezryth commented May 26, 2024

crui3er commented May 31, 2024

ur3an0 commented Jun 9, 2024

sabrigo commented Jun 13, 2024

bodeg commented Jun 15, 2024

wdcossey commented Jun 19, 2024

rhires commented Jun 24, 2024

dellis1972 commented Jun 24, 2024

kidmar commented Jun 26, 2024

Orgbrat commented Jun 28, 2024

dellis1972 commented Jun 28, 2024

Orgbrat commented Jun 28, 2024

hansmbakker commented Jun 28, 2024

pjt33 commented Jul 10, 2024 •

edited

Loading

dellis1972 commented Jul 10, 2024

ziomek64 commented Jul 16, 2024

jonathanpeppers commented Jul 31, 2024

PredatH0r commented Aug 1, 2024

zijianhuang commented Sep 3, 2024

grendello commented Sep 3, 2024

build issue typemaps.x86_64.ll: error: Could not open input file: no such file or directory #8967

build issue typemaps.x86_64.ll: error: Could not open input file: no such file or directory #8967

Comments

hansmbakker commented May 20, 2024 • edited Loading

Android application type

Affected platform version

Description

Steps to Reproduce

Did you find any workaround?

Relevant log output

hansmbakker commented May 20, 2024 • edited Loading

hansmbakker commented May 21, 2024

grendello commented May 22, 2024

hansmbakker commented May 23, 2024

hansmbakker commented May 24, 2024 • edited Loading

dezryth commented May 25, 2024

dezryth commented May 26, 2024

crui3er commented May 31, 2024

ur3an0 commented Jun 9, 2024

sabrigo commented Jun 13, 2024

bodeg commented Jun 15, 2024

wdcossey commented Jun 19, 2024

rhires commented Jun 24, 2024

dellis1972 commented Jun 24, 2024

kidmar commented Jun 26, 2024

Orgbrat commented Jun 28, 2024

dellis1972 commented Jun 28, 2024

Orgbrat commented Jun 28, 2024

hansmbakker commented Jun 28, 2024

pjt33 commented Jul 10, 2024 • edited Loading

dellis1972 commented Jul 10, 2024

ziomek64 commented Jul 16, 2024

jonathanpeppers commented Jul 31, 2024

PredatH0r commented Aug 1, 2024

zijianhuang commented Sep 3, 2024

grendello commented Sep 3, 2024

hansmbakker commented May 20, 2024 •

edited

Loading

hansmbakker commented May 20, 2024 •

edited

Loading

hansmbakker commented May 24, 2024 •

edited

Loading

pjt33 commented Jul 10, 2024 •

edited

Loading