[WIP] [CMAKE] link libc++ explicitly on darwin

[justice-adams-apple]

This is more of a PR for discussion. On Darwin these libraries require libc++, and rather than rely on the compiler to add the libc++ argument (which may be platform dependent) or relying on a flag added in a given source file as is with swift Core, It would be better to explicitly link in the c++ stdlib.

Outstanding question: Does it make sense to do the same for other platforms? Can we make assumptions about which C++ stdlib is being used on a given platform? Perhaps there's a more CMAKE native way to say "link in the C++ stdlib" on a given platform?

[etcwilde]

We will likely want a way to specify the C++ flavor on all platforms. Linux usually has libstdc++, but we have use-cases where using libc++ is preferable. Windows has their C++ runtime, but there are likely cases where we want to use libc++ there too.
I think we should have the same mechanism for specifying the desired C++ runtime across platforms. The value of this variable should then be exported by SwiftCoreConfig.cmake so that the platform overlays and supplemental libraries can use it as a default to ensure that all parts are building with the same C++ flavor.

[compnerd]

I think that the mechanism that we have today for this is -Xcc -stdlib=libc++ -Xclang-linker -stdlib=libc++. This will automatically link against the right C++ runtime.

However, if you want to explicitly hoist that away from the linker driver, that is a tricky proposition. Linking against the C++ runtime requires careful orchestration of the linker as the argument ordering is material and must have any possible dependencies listed as well. For example, your change here is invalid, you should obviously be doing -lc++ -lc++abi -lc++ -lc -lclang_rt.aarch64. There is a circular dependency between libc++ and the ABI runtime. I assume because this is being PoC'ed on Darwin, you would also assume libc++abi rather than say libcxxabi. Resolving the circular dependency then introduces the dependency on the compiler runtime. However, you also need to account for the libc dependency which must now come after the C++ runtime. This is a dark art and one that I suggest we do not pick up. This was one of the biggest reasons for using clang or clang++ as the linker driver, with swift being the driver-driver-driver.

[etcwilde]

I think that the mechanism that we have today for this is -Xcc -stdlib=libc++ -Xclang-linker -stdlib=libc++. This will automatically link against the right C++ runtime.

I was thinking in terms of also ensuring that we produce the right C++ interop overlays too since they're different between libstdc++ and libc++. I believe that those should be built against (and for) the same C++ runtime as the libswiftCore/Concurrency, no?

[compnerd]

I think that the mechanism that we have today for this is -Xcc -stdlib=libc++ -Xclang-linker -stdlib=libc++. This will automatically link against the right C++ runtime.

I was thinking in terms of also ensuring that we produce the right C++ interop overlays too since they're different between libstdc++ and libc++. I believe that those should be built against (and for) the same C++ runtime as the libswiftCore/Concurrency, no?

No, I think that they C++ interop layers should be able to support any C++ runtime, but would need to be built for a particular C++ runtime. Consider the case that The Browser Company has been working with and on - multiple isolated C++ runtimes. We should be able to target both libc++ and msvcprt on Windows at the very least (if not more).

[etcwilde]

No, I think that the C++ interop layers should be able to support any C++ runtime, but would need to be built for a particular C++ runtime.

It'll be something that you can override, sure. I don't know that we want to encourage folks to have multiple C++ runtime flavors in their process at the same time though and I think that the default should do the right thing by default. If the swiftCore is built with libcxx, that should be an exported option. Then the C++ interop project can use that to set the same default. If you want to override it in your build, or build the interop libraries for another C++ runtime, go ahead, though that can't be a supported configuration since C++ doesn't guarantee that it is safe to have more than one runtime at a time.

[justice-adams-apple]

Thanks for the help all. Dropping this in favor of #80139 which changes to correctly use the C++ linker and thus we get the benefit of linking the correct stdlib. If we decide in the future we want more customizability with respect to the stdlib used we can revisit this

[edymtt]

Duplicate of #80139