Consolidate LocateNativeCompiler target

[am11]

No description provided.

[am11]

Opened #103409, as it's failing on other PRs as well. Rest of the failures are unrelated to PR changes.

[MichalStrehovsky]

Thanks, this is an awesome improvement, but we need to get official builds stabilized first since we didn't have any for a week. Build work has a high chance of breaking stuff. I'll mark no-merge for now.

[sbomer]

LGTM once our official builds are unblocked. Thanks a lot!

[sbomer]

Do you know why this is no longer needed?

[am11]

This should be handled by

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets

Line 46 in b1f63db

<CrossCompileAbi Condition="$(CrossCompileRid.StartsWith('linux-musl-')) or $(CrossCompileRid.StartsWith('alpine-'))">musl</CrossCompileAbi>

(since it's required by public consumption as well)

[am11]

Failures are unrelated according to Build Analysis. I think it would be good to run outerloop nativeaot leg against this PR to rule out any latent surprises.

[jkotas]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

LGTM. Thanks!

@sbomer Could you please review this as well? Most of the changes are in the trimming tests.

[filipnavara]

We generally need to specify the @rpath/-prefixed name on macOS for libraries. Is that done somewhere else now? What is the output for otool -l before and after?

[am11]

Is that done somewhere else now?

Seems to me like an avoidable duplicate:

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets

Line 217 in 7b69459

<LinkerArg Include="-Wl,-install_name,&quot;$(SharedLibraryInstallName)&quot;" Condition="'$(_IsiOSLikePlatform)' == 'true' and '$(NativeLib)' == 'Shared'" />

Can we use it for all apple platforms? Or are there use-cases when we explicitly don't need it?

[filipnavara]

Can we use it for all apple platforms? Or are there use-cases when we explicitly don't need it?

I'd say we can. We would need to check with Xamarin workloads to ensure that it doesn't break anything.

Note that generally Xamarin workloads have an SDK code on the consumption side where it fixes up the paths with install_name_tool if they are wrong, so I don't expect it to break anything there. I am more concerned that the workload may also specify -install_name on the library compilation side and it would collide if we add it in the NativeAOT linker args.

[am11]

With 9a97e5e the behavior is:

-      cmdsize 72
-         name bin/Release/net9.0/osx-arm64/native/helloworld.dylib (offset 24)
+      cmdsize 48
+         name @rpath/helloworld.dylib (offset 24)

• User can skip setting install_name with SkipInstallName
• If user has <LinkerArg Include="-Wl,-install_name,@rpath/TheirName" /> type of thing specified in their project, TheirName takes precedence with SkipInstallName=true

What do you think?

cDAC (the project being modified) is currently only used for testing in the repo, which is working, so I think we can live with it without waiting for next SDK update which won't be long (10.0 alpha1).

[jkotas]

cc @lambdageek

[filipnavara]

LGTM