[NativeAOT] Use NativeLinker and invoke lld directly for linking

[sbomer]

Replace the clang Exec invocation with the LinkNativeAotSharedLibrary task
that calls ld.lld directly from the NDK. The task uses NativeLinker.cs which
handles response files, ABI-specific flags, and debug symbol stripping.

Compute NDK paths for CRT objects (crtbegin_so.o/crtend_so.o), compiler-rt
builtins, and libunwind. Pass system libraries (dl, z, log, m, c) and
library search paths explicitly.

Fix NativeLinker.cs quoting for soname with spaces, and guard against empty
runtime pack library directory.

Builds on #11148.
Contributes to #10697

[Copilot]

Pull request overview

This PR shifts NativeAOT shared-library linking to use the existing NativeLinker infrastructure (response files, ABI flags, symbol stripping) instead of invoking the NDK clang wrapper, and wires this into the NativeAOT MSBuild targets.

Changes:

• Extend NativeLinker with NativeAOT-focused linker options (export-dynamic, version scripts, linker scripts, debug section compression, extra -L paths, etc.).
• Add a new MSBuild task (LinkNativeAotSharedLibrary) that drives NativeLinker to produce a .so from ILC output + runtime/static archives.
• Update Microsoft.Android.Sdk.NativeAOT.targets to set NativeLib=static, enable unmanaged entrypoint exports, and run the new link step after LinkNative.

Show a summary per file

File	Description
src/Xamarin.Android.Build.Tasks/Utilities/NativeLinker.cs	Adds configurable linker options needed for NativeAOT and fixes argument quoting/guards.
src/Xamarin.Android.Build.Tasks/Tasks/LinkNativeAotSharedLibrary.cs	New task orchestrating NativeAOT .so linking via NativeLinker.
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.NativeAOT.targets	MSBuild integration: produce .a from ILC then link final .so via the new task, plus NDK CRT/rt/unwind inputs.

Copilot's findings

Comments suppressed due to low confidence (1)

src/Xamarin.Android.Build.Tasks/Tasks/LinkNativeAotSharedLibrary.cs:140

• Directory.CreateDirectory (Path.GetDirectoryName (LinkerScript)!) can throw if LinkerScript is just a filename (no directory component), because Path.GetDirectoryName() would return null. Avoid the null-forgiving operator here and handle the null case explicitly (or use IntermediateOutputPath as the directory when none is provided).

		if (!LinkerScriptContent.IsNullOrEmpty () && !LinkerScript.IsNullOrEmpty ()) {
			Directory.CreateDirectory (Path.GetDirectoryName (LinkerScript)!);
			File.WriteAllText (LinkerScript, LinkerScriptContent);
		}

• Files reviewed: 3/3 changed files
• Comments generated: 4

[Copilot]

SaveDebugSymbols is set to true unconditionally. With StripDebugSymbols = !DebugBuild, this causes Debug builds to still run NativeLinker.ExtractDebugSymbols() which strips debug info from the output .so. Align this with the existing linker usage by setting SaveDebugSymbols consistently with StripDebugSymbols (e.g., SaveDebugSymbols = !DebugBuild).

Suggested change

	SaveDebugSymbols = true,
	SaveDebugSymbols = !DebugBuild,

[Copilot]

The task rebuilds new TaskItem instances for NativeObject/NativeLibraries/AdditionalObjectFiles/CompilerRuntimeLibraries using only ItemSpec + Abi, which drops important metadata such as LinkWholeArchive / DontExportSymbols. NativeLinker relies on these metadata flags to emit --whole-archive, --exclude-libs, etc., so this can change link semantics. Prefer cloning the incoming ITaskItem (e.g., new TaskItem (lib)) and then overriding/setting Abi as needed, so all linker-related metadata is preserved.

[Copilot]

Link item ordering is currently NativeObject + static archives, then -l<system> libraries, and only then additional .o files. With static .a archives and --as-needed, link order affects symbol resolution; object files that reference symbols in earlier archives or libraries may fail to resolve because the linker has already processed them. Consider placing all object files (NativeObject + AdditionalObjectFiles) before static archives, and keeping SystemLibraries after all objects/archives (similar to the ordering logic in LinkNativeRuntime.OrganizeCommandLineItemsCLR).

[Copilot]

The null-forgiving operator (!) is used on [Required] task properties. This can hide nullability issues and makes it easier to accidentally get a NullReferenceException before MSBuild's [Required] validation runs. Prefer non-nullable [Required] properties with safe defaults (or explicit null checks at the start of RunTask()), consistent with other task properties in this file that use = "" / =[].

This issue also appears on line 137 of the same file.

Suggested change

	public ITaskItem NativeObject { get; set; } = null!;
	/// <summary>
	/// The output shared library path (e.g., libTestApp.so)
	/// </summary>
	[Required]
	public ITaskItem OutputSharedLibrary { get; set; } = null!;
	public ITaskItem NativeObject { get; set; } = new TaskItem ("");
	/// <summary>
	/// The output shared library path (e.g., libTestApp.so)
	/// </summary>
	[Required]
	public ITaskItem OutputSharedLibrary { get; set; } = new TaskItem ("");