From @am11 in #84794 (comment):
- we can no longer build runtime repo with binutils alone.
i.e. LinkerFlavor=lld if target==linux constructs added are missing and Compiler!=gcc condition; we set Compiler at the start of build:
|
arguments="$arguments /p:Compiler=$compiler /p:CppCompilerAndLinker=$compiler" |
(maps to ./build.sh -gcc)
The ability to compile with gcc+binutils is tested by the gcc product build leg, but this doesn't cover test builds. Conditions similar to
|
<UseLLVMLinker Condition="'$(CppCompilerAndLinker)' == 'clang' and '$(TargetOS)' == 'linux'">true</UseLLVMLinker> |
need to be added to nativeaot test builds. I believe this would cover building with gcc+binutils.
That still leaves the scenario of building with clang+bfd (where clang and binutils are installed, but lld isn't). From #84794 (comment):
changes in #84148 will "force" fuse-ld=lld unconditionally, disregarding #2's introspection based linker selection, and fail the build because we didn't install lld-16
When using clang as the linker driver, the NativeAot targets either explicitly use bfd (the default), or can be made to use lld via LinkerFlavor. So the fix for this would be to perform detection of lld when using the clang compiler, and set LinkerFlavor based on the result.
From @am11 in #84794 (comment):
The ability to compile with gcc+binutils is tested by the gcc product build leg, but this doesn't cover test builds. Conditions similar to
runtime/src/coreclr/tools/aot/ILCompiler/ILCompiler.csproj
Line 53 in dbd4233
That still leaves the scenario of building with clang+bfd (where clang and binutils are installed, but lld isn't). From #84794 (comment):
When using clang as the linker driver, the NativeAot targets either explicitly use
bfd(the default), or can be made to uselldviaLinkerFlavor. So the fix for this would be to perform detection oflldwhen using the clang compiler, and setLinkerFlavorbased on the result.