[windows] fix flaky linker error when building LLDB

[charles-zablit]

When building LLDB on Windows with build.ps1, the following linker error happens, especially after rebuilding incrementally. The error sometimes goes away after deleting CMakeCache.txt, but that's not reliable.

[1/4][ 25%][39.728s] Linking CXX shared library bin\liblldb.dll
FAILED: bin/liblldb.dll lib/liblldb.lib
C:\WINDOWS\system32\cmd.exe /C "cd . && "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_dll --intdir=tools\lldb\source\API\CMakeFiles\liblldb.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\arm64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\arm64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~2\2022\COMMUN~1\VC\Tools\MSVC\1443~1.348\bin\HOSTAR~1\arm64\link.exe /nologo @CMakeFiles\liblldb.rsp  /out:bin\liblldb.dll /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:19.1 /machine:ARM64 /INCREMENTAL:NO && cd ."
LINK: command "C:\PROGRA~1\MICROS~2\2022\COMMUN~1\VC\Tools\MSVC\1443~1.348\bin\HOSTAR~1\arm64\link.exe /nologo @CMakeFiles\liblldb.rsp /out:bin\liblldb.dll /implib:lib\liblldb.lib /pdb:bin\liblldb.pdb /dll /version:19.1 /machine:ARM64 /INCREMENTAL:NO /MANIFEST:EMBED,ID=2" failed (exit code 1120) with the following output:
   Creating library lib\liblldb.lib and object lib\liblldb.exp
swiftrt.obj : error LNK2019: unresolved external symbol __imp_swift_addNewDSOImage referenced in function "void __cdecl swift_image_constructor(void)" (?swift_image_constructor@@YAXXZ)
bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
ninja: build stopped: subcommand failed.

This PR fixes this build error and removes the use of SWIFT_ALL_LIBS as it's not referenced anywhere else.

[adrian-prantl]

Can you add a comment here that this works around an issue on windows and maybe even ifdef this so we only do this on windows?

[charles-zablit]

Fixed 👍

[adrian-prantl]

It wouldn't hurt to be more verbose and mention which symbol is missing, and that we don't actually think this is the correct solution, but merely a workaround.

[charles-zablit]

Made the comment more explicit 👍

[compnerd]

This really is the right solution - if you have Swift code in the image, you need to have swiftrt.obj linked in to register the metadata with the runtime, and thus you need to register the runtime.

If this is truly a workaround, then we should probably indicate what dependency we are pulling in that we should not be which is resulting in Swift code being pulled into the module.

[charles-zablit]

If this is truly a workaround, then we should probably indicate what dependency we are pulling in that we should not be which is resulting in Swift code being pulled into the module.

Could it be linked to these commits? swiftlang/swift@8cb86ac - swiftlang/swift@0c42b57?

I'm not sure how to determine if it's a workaround or the right solution.

[compnerd]

No, neither of those are related. The first is a change to the stubs, and the second is limited to ELF. The way to determine if this is a workaround or the right solution is to understand why there is any Swift code in the module. If you are supposed to have Swift code, then this is the right fix - Swift code generally requires that you are linking to swiftCore as that is what provides the implementation for the basic types.

[adrian-prantl]

@swift-ci test