Android framework version
net9.0-android
Affected platform version
9.0.100-preview.6.24328.19
Description
A net9.0-android (but probably also net8.0-android) project with a & (ampersand) character in it can be created and built, except when AOT is involved, which then fails.
Steps to Reproduce
Run these:
dotnet new android -o "android&stuff"
cd "android&stuff"
dotnet build "android&stuff.csproj" -c Release
Note that running ``dotnet build "android&stuff.csproj"` works just fine.
The result is several errors like this:
android&stuff failed with 1 error(s) (0.8s)
C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\targets\Microsoft.Android.Sdk.Aot.targets(109,5): error :
Precompiling failed for E:\repos\BugRepros\andr\android&stuff\obj\Release\net9.0-android\android-arm64\linked\android&stuff.dll with exit code 1.
missing input files on command line
`aarch64-linux-android-as` takes a subset of arguments accepted by the GNU Assembler (gas) program.
Accepted options are limited to the ones used by Xamarin.Android and Mono/dotnet AOT, more can be added as-needed.
Some options are accepted but ignored, either because they are ignored by GAS as well or because they are used by
Xamarin.Android or Mono/dotnet AOT, but not needed by `llvm-mc`. All the unsupported options will cause the wrapper
to fail with an error message.
Since `llvm-mc` does not support compiling multiple source files at the same time, this GAS behavior is emulated
by running `llvm-mc` once per each input file and using the `ld` linker in the end to merge all the discrete output
files into the single file indicated by the `-o` option.
Command line options are compatibile with GAS version 2.38
Currently supported options are:
All targets
-o FILE path to the output object file
--warn don't suppress warning messages
-g | --gen-debug generate debug information in the output object file
x86/x86_64 targets
--32 output a 32-bit object [ignored, `llvm-mc` is always invoked for the right target]
--64 output a 64-bit object [ignored, as above]
armeabi/arm32 targets
-mfpu=FPU select floating-point architecture for the target
Ignored by GAS and this wrapper
--divide
-k
--nocpp
-Qn
-Qy
-s
-w
-X
Wrapper options, not passed to `llvm-mc`
-h | --help show this help screen
-V show version
--version show version and exit
The system cannot find the path specified.
The system cannot find the path specified.
AOT of image E:\repos\BugRepros\andr\android&stuff\obj\Release\net9.0-android\android-arm64\linked\android&stuff.dll failed.
Mono Ahead of Time compiler - compiling assembly E:\repos\BugRepros\andr\android&stuff\obj\Release\net9.0-android\android-arm64\linked\android&stuff.dll
AOTID 885475ED-118C-B68C-C29B-8D3F5B8FCFAE
Compiled: 3/3
You can run step (3) with the -bl parameter to get a binlog with more details.
But it seems that the & char is causing some paths to be troublesome with the AOT pipeline. The same project without the & in it works fine too.
Did you find any workaround?
Don't use & char in project name. But there could be other problematic chars as well. Then again, I recently found that the whole Android stack is at best friendly to ASCII chars in paths, but not all ASCII chars (forget Unicode entirely).
Relevant log output
No response
Android framework version
net9.0-android
Affected platform version
9.0.100-preview.6.24328.19
Description
A net9.0-android (but probably also net8.0-android) project with a
&(ampersand) character in it can be created and built, except when AOT is involved, which then fails.Steps to Reproduce
Run these:
dotnet new android -o "android&stuff"cd "android&stuff"dotnet build "android&stuff.csproj" -c ReleaseNote that running ``dotnet build "android&stuff.csproj"` works just fine.
The result is several errors like this:
You can run step (3) with the
-blparameter to get a binlog with more details.But it seems that the
&char is causing some paths to be troublesome with the AOT pipeline. The same project without the&in it works fine too.Did you find any workaround?
Don't use
&char in project name. But there could be other problematic chars as well. Then again, I recently found that the whole Android stack is at best friendly to ASCII chars in paths, but not all ASCII chars (forget Unicode entirely).Relevant log output
No response