Fuchsia already defaults to libc++ and compiler-rt, but we want to use
these as default runtimes even on the host platform.
Details
- Reviewers
beanz mcgrathr EricWF - Commits
- rG0f0fb0a06f32: [CMake] Use libc++ and compiler-rt as default libraries in Fuchsia toolchain
rL327860: [CMake] Use libc++ and compiler-rt as default libraries in Fuchsia toolchain
rC327860: [CMake] Use libc++ and compiler-rt as default libraries in Fuchsia toolchain
Diff Detail
- Repository
- rC Clang
Event Timeline
In principle this should be OK since we're unconditionally building the runtimes for default.
However, this means that any dynamically-linked host builds will assume our toolchain-provided shared libraries are available on the runtime host in standard library places.
I don't think we want that. Perhaps we could make -static-libstdc++ default in our host targets. But that's not really enough, since compiler-rt has some too. Probably better to just disable building the shared libraries altogether for the host targets.
LGTM with comment added but if a different approach will be required for multiple Linux targets (which we all treat as "hostish") then it's worth at least thinking about that now.
cmake/caches/Fuchsia-stage2.cmake | ||
---|---|---|
38 | It's not completely obvious (to me) that these apply to the "default target" build but not to the other LLVM_RUNTIME_TARGETS builds. We recently discussed enabling other *-linux targets (AFAIK we might as well enable {x86_64,aarch64}-linux regardless of host, even for Mac hosts). We'd want these settings for those too. Would that have to be done differently than thsi? |
This is something I was already thinking about. Ideally, in our toolchain, we would build runtimes for all host and target platforms we support, i.e. on every host (Linux, macOS and Windows) we would build runtimes for i386, x86_64 and aarch64 Linux, x86_64 macOS, x86_64 Windows, and x86_64 and aarch64 Fuchsia. This means that the toolchain on every platform can target every other platform as long as you provide the right sysroot. However, there are two issues I'm aware of:
- The compiler-rt build for host is different from the cross-target build: In the cross-target build, it only builds artifacts for the specified target triple. However, on Linux it always does a multilib build and on macOS it produces fat archives for all supported platforms.
- Clang driver currently assumes that runtimes for host platform live in <toolchain>/lib/. In Fuchsia, we support runtimes being in <toolchain>/lib/<triple> but no other driver does.
To support what I described above, we would have to move to a setup when host platform isn't treated specially as it's today but it's just another triple. That's going to require some refactoring and cleanup. @beanz might have some opinion on this as well since this is something we already discussed before on IRC.
@phosek, I would love to see compiler-rt fully refactored so that we target one triple at a time always. I'd also love to see the clang driver refactored so that the code to resolve paths to runtime libraries was shared so we follow the same conventions across all driver implementations.
These are both large projects with a lot of stakeholders, and I don't expect that I'll be much use on it anytime soon.
It's not completely obvious (to me) that these apply to the "default target" build but not to the other LLVM_RUNTIME_TARGETS builds.
A comment here would be good.
We recently discussed enabling other *-linux targets (AFAIK we might as well enable {x86_64,aarch64}-linux regardless of host, even for Mac hosts). We'd want these settings for those too. Would that have to be done differently than thsi?