Specify "-rtlib=compiler-rt" on Linux as required for some of Swift's numeric conversion symbols.

[artemcm]

Resolves rdar://104134160

[artemcm]

@swift-ci test

[eeckstein]

lgtm

[artemcm]

Looks like it may be causing a test failure on Linux on main:
https://ci.swift.org/job/swift-PR-Linux/5421/console

error: link command failed with exit code 1 (use -v to see invocation)
/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/usr/lib/swift_static/linux/libswiftCore.a(Errors.cpp.o):Errors.cpp:function swift::withCurrentBacktrace(std::function<void (void**, int)>): error: undefined reference to '_Unwind_Backtrace'
/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/usr/lib/swift_static/linux/libswiftCore.a(Errors.cpp.o):Errors.cpp:function swift::printCurrentBacktrace(unsigned int): error: undefined reference to '_Unwind_Backtrace'
/home/build-user/build/buildbot_linux/none-swift_package_sandbox_linux-x86_64/usr/lib/swift_static/linux/libswiftCore.a(Errors.cpp.o):Errors.cpp:function SwiftUnwindFrame(_Unwind_Context*, void*): error: undefined reference to '_Unwind_GetIP'
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

error: command failed with exit status: 1

[eeckstein]

@mikeash When linking with the clang rt, can this be solved by removing the #elif defined(__ELF__) case in withCurrentBacktraceImpl?

[mikeash]

I think so. /cc @al45tair who would know better than I.

[al45tair]

Does that not just mean that we also need -lunwind?

[bnbarham]

Could we instead make this change when building Clang? Ie. set CLANG_DEFAULT_RTLIB and CLANG_DEFAULT_UNWINDLIB (which both default to libgcc but we could instead have compiler-rt and libunwind respectively).

[artemcm]

Could we instead make this change when building Clang? Ie. set CLANG_DEFAULT_RTLIB and CLANG_DEFAULT_UNWINDLIB (which both default to libgcc but we could instead have compiler-rt and libunwind respectively).

If this achieves the same thing (clang linker driver defaulting to rtlib=compiler-rt) then I'd be in favor of this approach also. But I'll let others weigh in.

[bnbarham]

If this achieves the same thing (clang linker driver defaulting to rtlib=compiler-rt) then I'd be in favor of this approach also. But I'll let others weigh in.

@al45tair / @mikeash any thoughts?

[al45tair]

I have no problem with it either way, as long as it works :-)

I think it might be slightly cleaner to configure Clang, if that way will work, not least because then we won't have oddities like things built with our Clang linking with libgcc but things built with Swift itself linking with libcompiler-rt and libunwind.

[compnerd]

Accidentally linking libgcc would be a problem - libgcc is an unwinder, and mixing unwinders will lead to crashes as the context is implementation defined.

[artemcm]

@swift-ci test

[artemcm]

Re-running cross-repo tests in swiftlang/swift#60581, but from what I saw last time, adding -lunwind does not help with failing test-cases in main CI if this is merged. So this PR cannot be merged in its current form.

[bnbarham]

Re-running cross-repo tests in swiftlang/swift#60581, but from what I saw last time, adding -lunwind does not help with failing test-cases in main CI if this is merged. So this PR cannot be merged in its current form.

IIUC we then had failures because of missing unwind errors instead.