smeenai added a comment. In D158476#4609243 <https://reviews.llvm.org/D158476#4609243>, @srhines wrote:
> This approach LGTM, assuming that https://reviews.llvm.org/D140925 lands as > well to ensure that the triple does use `androideabi`, since it would prevent > custom build setups from needing additional help. @phosek is working on that one, but I think this is useful even without it, because you just need to use `android` in your triple when building the runtimes, and can use `androideabi` everywhere else. I'll put up an example runtimes build setup with that to demonstrate. >> (Aside: why do we need to produce runtime libraries for different versions >> in the first place? We want one for the minimum OS version we support, of >> course, but then there's important additions like version 29 adding ELF TLS >> support and version 31 adding a thread properties API used by LSAN, so >> building libraries targeting those important versions and having them be >> dynamically selected based on your target OS version is super useful. We >> could build the runtime libraries for every single OS version we wanted to >> support, but that's a lot of versions (at least 21 through 31, times four >> architectures), which is wasteful for both build times and toolchain >> distribution size.) > > I don't think we need all the versions, but today we really only use 21 > (lowest level), and 30 (a conservative level for the platform that supports > all our apexes). Ideally we'd also pick up the latest platform version, and > we probably should explicitly call out 29 for ELF TLS, so that would be ~4 > supported levels, but maybe we can use 29 instead of 30 to cut it to ~3 for > most architectures. Ah, yeah, https://reviews.llvm.org/D85927 dynamically detects the thread properties API, so we don't need an explicit build for 31. An explicit build with ELF TLS is still required though. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D158476/new/ https://reviews.llvm.org/D158476 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
