smeenai added a comment. In D158476#4605360 <https://reviews.llvm.org/D158476#4605360>, @MaskRay wrote:
>> // Android target triples contain a target version. If we don't have >> libraries for the exact target version, we should fall back to the next >> newest version or a versionless path, if any. > > An Android maintainer can override my opinion but my feeling is that this > ad-hoc rule probably should be the responsibility of the file hierarchy > instead of clangDriver. This really easy to cause mix-and-match situations > where the problem is on the user side but the user may blame Clang. > > This can be implemented by adding symlinks in the file hierarchy. That was one of the alternatives I brought up in https://discourse.llvm.org/t/handling-version-numbers-in-per-target-runtime-directories/62717, but symlinks are complicated on Windows, and you'd also have to add build system code to create those symlinks, so I don't think it'll be a clear win. Are you concerned with falling back to the next newest version or the versionless path (or both)? I think the next newest version is pretty inline with general OS compatibility: if you don't have version N, look for version N - 1, N - 2, etc (since they're forward compatible, see also https://discourse.llvm.org/t/handling-version-numbers-in-per-target-runtime-directories/62717/13). The versionless path is a little less principled IMO (though I guess you could see it as implicitly being compatible with any version) ... maybe we could get rid of that if Chrome is okay moving to a versioned directory. (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.) 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
