[cmake] Don't try creating an executable when detecting the linker

[ldionne]

Summary

On most platforms, the linker detection command that we run ends up being
something like clang++ -Wl,-v or clang++ -Wl,--version. This usually
fails with a missing reference to _main because we don't have any input
file. However, when compiling for a target that is implicitly freestanding,
the invocation actually succeeds and a dummy a.out file is created in
the current working directory. This is extremely annoying because it
creates a a.out file at the root of the monorepo when running CMake
configuration from the root.

[ldionne]

Note that I don't intend this to work on Windows -- I'm not too sure how to specify "no output file" in a generic manner that will work on all platforms.

[smeenai]

I think this might potentially break cross-compilation on Windows. We're in a NOT WIN32 block here, but that means you're not targeting Windows; you could still be targeting e.g. Linux but building on a Windows machine. I think NUL is the Windows equivalent, and you could have a CMAKE_HOST_WIN32 block, but it'll depend on how CMake invokes an execute_process command. (I have a Windows machine handy and can experiment with that, if you'd like.) That being said

This is extremely annoying because it creates a a.out file at the root of the monorepo when running CMake configuration from the root.

I thought we forced out-of-tree builds (i.e. you needed to have a dedicated build directory and couldn't just run a CMake configuration from the source tree)? Having a separate build directory seems nicer in general, unless I'm misunderstanding what you meant.

[smeenai]

Removing from my queue in the meantime

[ldionne]

In D125827#3520509, @smeenai wrote:

I think this might potentially break cross-compilation on Windows. We're in a NOT WIN32 block here, but that means you're not targeting Windows; you could still be targeting e.g. Linux but building on a Windows machine. I think NUL is the Windows equivalent, and you could have a CMAKE_HOST_WIN32 block, but it'll depend on how CMake invokes an execute_process command. (I have a Windows machine handy and can experiment with that, if you'd like.) That being said

Hmm, I just tried it out on a Windows machine and it seems to work.

I thought we forced out-of-tree builds (i.e. you needed to have a dedicated build directory and couldn't just run a CMake configuration from the source tree)? Having a separate build directory seems nicer in general, unless I'm misunderstanding what you meant.

We do force out of tree builds, however CMake can be invoked as cmake -S llvm -B <path-to-build>, in which case a.out will be generated in whatever directory you happen to be in.

[ldionne]

Try to handle Windows hosts.

[smeenai]

LGTM, thanks.

In D125827#3525320, @ldionne wrote:

In D125827#3520509, @smeenai wrote:

I think this might potentially break cross-compilation on Windows. We're in a NOT WIN32 block here, but that means you're not targeting Windows; you could still be targeting e.g. Linux but building on a Windows machine. I think NUL is the Windows equivalent, and you could have a CMAKE_HOST_WIN32 block, but it'll depend on how CMake invokes an execute_process command. (I have a Windows machine handy and can experiment with that, if you'd like.) That being said

Hmm, I just tried it out on a Windows machine and it seems to work.

To be clear, were you building for Windows on a Windows machine, or targeting some other platform? The NOT WIN32 above would have already taken care of the building for Windows on Windows case.

I thought we forced out-of-tree builds (i.e. you needed to have a dedicated build directory and couldn't just run a CMake configuration from the source tree)? Having a separate build directory seems nicer in general, unless I'm misunderstanding what you meant.

We do force out of tree builds, however CMake can be invoked as cmake -S llvm -B <path-to-build>, in which case a.out will be generated in whatever directory you happen to be in.

Ah, interesting. That's unfortunate, though I guess it makes sense.

[phosek]

LGTM

[ldionne]

In D125827#3525570, @smeenai wrote:

LGTM, thanks.

In D125827#3525320, @ldionne wrote:

In D125827#3520509, @smeenai wrote:

I think this might potentially break cross-compilation on Windows. We're in a NOT WIN32 block here, but that means you're not targeting Windows; you could still be targeting e.g. Linux but building on a Windows machine. I think NUL is the Windows equivalent, and you could have a CMAKE_HOST_WIN32 block, but it'll depend on how CMake invokes an execute_process command. (I have a Windows machine handy and can experiment with that, if you'd like.) That being said

Hmm, I just tried it out on a Windows machine and it seems to work.

To be clear, were you building for Windows on a Windows machine, or targeting some other platform? The NOT WIN32 above would have already taken care of the building for Windows on Windows case.

Ugh, yeah, then I guess my testing wasn't sound. Do you have a setup to target Linux from a windows host?

[smeenai]

In D125827#3534224, @ldionne wrote:

In D125827#3525570, @smeenai wrote:

LGTM, thanks.

In D125827#3525320, @ldionne wrote:

In D125827#3520509, @smeenai wrote:

I think this might potentially break cross-compilation on Windows. We're in a NOT WIN32 block here, but that means you're not targeting Windows; you could still be targeting e.g. Linux but building on a Windows machine. I think NUL is the Windows equivalent, and you could have a CMAKE_HOST_WIN32 block, but it'll depend on how CMake invokes an execute_process command. (I have a Windows machine handy and can experiment with that, if you'd like.) That being said

Hmm, I just tried it out on a Windows machine and it seems to work.

To be clear, were you building for Windows on a Windows machine, or targeting some other platform? The NOT WIN32 above would have already taken care of the building for Windows on Windows case.

Ugh, yeah, then I guess my testing wasn't sound. Do you have a setup to target Linux from a windows host?

I think Android might be the easiest thing to target. You can download the Android NDK and target it with -DCMAKE_TOOLCHAIN_FILE=path_to_ndk/build/cmake/android.toolchain.cmake; I don't know how much of LLVM will build, but you should at least be able to test the CMake configure that way.

[ldionne]

Okay, I just managed to try this command on Windows targeting the Android NDK, and the CMake build fails extremely early. However, when I move the check to a different place, it works as intended. In other words, if someone wants to target Android from Windows, it looks like LLVM's not going to cooperate -- however this patch won't make things worse.

[smeenai]

SGTM

llvm/cmake/modules/AddLLVM.cmake

if(APPLE)
     # Linkers with ld64-compatible flags.
     set(version_flag "-Wl,-v")
   else()
     # Linkers with BFD ld-compatible flags.
     set(version_flag "-Wl,--version")
   endif()
 
   if(LLVM_USE_LINKER)
-    set(command ${CMAKE_C_COMPILER} -fuse-ld=${LLVM_USE_LINKER} ${version_flag})
+    set(command ${CMAKE_C_COMPILER} -fuse-ld=${LLVM_USE_LINKER} ${version_flag} -o /dev/null)
   else()
     separate_arguments(flags UNIX_COMMAND "${CMAKE_EXE_LINKER_FLAGS}")
-    set(command ${CMAKE_C_COMPILER} ${flags} ${version_flag})
+    set(command ${CMAKE_C_COMPILER} ${flags} ${version_flag} -o /dev/null)
   endif()
   execute_process(
     COMMAND ${command}
     OUTPUT_VARIABLE stdout
     ERROR_VARIABLE stderr
     )
 
   if(APPLE)