Closed georg-jung closed 2 years ago
error : unable to find python in $PATH
- You need python (try 3.6+) installed.
This issue has been marked needs-author-action
and may be missing some important information.
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
Author: | georg-jung |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `area-Codegen-AOT-mono`, `needs-author-action` |
Milestone: | - |
Sorry, I missed that when creating the issue and thought dotnet workload install wasm-tools
would bring all relevant dependencies (might be great to issue a warning there when python is missing?). I fixed that in the meantime and will report back with my results, once my builds finish.
Is this expected to take more than 10min though?
#20 82.94 [100/102] netstandard.dll -> netstandard.dll.bc
#20 88.06 [101/102] System.Private.CoreLib.dll -> System.Private.CoreLib.dll.bc
#20 819.8 [102/102] DocumentFormat.OpenXml.dll -> DocumentFormat.OpenXml.dll.bc
#20 823.4 Compiling native assets with emcc with -Oz. This may take a while ...
#20 823.7 [1/3] pinvoke.c -> pinvoke.o [took 0.30s]
#20 823.8 [2/3] driver.c -> driver.o [took 0.38s]
There seems to be something special about DocumentFormat.OpenXml
. Trimming it takes 30min+, AoTing it takes quite long too.
It's in the messages that you shared:
#20 3542.8 /usr/share/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/7.0.0-preview.4.22229.4/Sdk/WasmApp.Native.targets(472,5):
error : unable to find python in $PATH [/src/src/AV.AvA.BlazorWasmClient/AV.AvA.BlazorWasmClient.csproj]
#20 3542.8 /usr/share/dotnet/packs/Microsoft.NET.Runtime.WebAssembly.Sdk/7.0.0-preview.4.22229.4/Sdk/WasmApp.Native.targets(472,5):
error MSB3073: The command "emcc --version" exited with code 1. [/src/src/AV.AvA.BlazorWasmClient/AV.AvA.BlazorWasmClient.csproj]
Yeah, AOT can take time. That particular assembly might be generics heavy.
We should check that when installing the workload though.
In .Net 7 preview with python3 installed it does build successfully (takes ~30min). Thanks for your help! And sorry for the non-issue.
If someone facing a similar situation finds this:
Description
I'm building a Blazor WASM app that should support export of data to the xlsx format. I chose ClosedXML as a library for xlsx production. My non-AoTed builds run fine in the browser. To achieve a production-ready runtime performance, I want to AoT my code prior to deploying it. ClosedXML depends on the Microsoft-maintained DocumentFormat.OpenXml library. I first tried AoTing my project with the .Net 6 SDK, which fails fast. After reading @radical's comment here I decided to give the current .Net 7 preview (4) a try instead. AoTing the assembly still fails on .Net 7. It takes quite some time before failing and produces more meaningful error messages though.
Side node: While trimming the assembly does work, it takes more than half an hour to complete.
/cc @radical
Reproduction Steps
AoT a blazor wasm project which uses ClosedXML, either using .Net 6 or using .Net 7 preview 4. See a relevant build log. Running this workflow with AoT enabled reproducibly fails. Executing the same docker build locally fails too.
Expected behavior
ClosedXML
library and its dependencyDocumentFormat.OpenXml
Actual behavior
AoTing ClosedXML and/or it's dependency DocumentFormat.OpenXml on .Net 7 preview 4 fails.
Regression?
Does not work using .Net 6 SDK or .Net 7 Preview 4 SDK. Everything does work if AoT is disabled.
Known Workarounds
No response
Configuration
No response
Other information
No response