[PATCH] D45639: [Driver] Support default libc++ library location on Darwin
Jonas Devlieghere via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Apr 21 11:20:45 PDT 2021
JDevlieghere added a comment.
In D45639#2705919 <https://reviews.llvm.org/D45639#2705919>, @phosek wrote:
> In D45639#2705702 <https://reviews.llvm.org/D45639#2705702>, @ldionne wrote:
>
>> In D45639#2703913 <https://reviews.llvm.org/D45639#2703913>, @JDevlieghere wrote:
>>
>>> This breaks `TestAppleSimulatorOSType.py ` on GreenDragon. First failed build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/
>>> [...]
>>>
>>> Based on your description above, shouldn't it prefer the libc++ form the sysroot?
>>
>> Actually, it's the other way around. In the discussion above, we say it's the toolchain path first, then anything provided with `-L`, and then the sysroot. Here you have a dylib in the toolchain root (assuming that's what `jenkins/workspace/lldb-cmake/lldb-build` is), so it's using that. It seems that the library built in the toolchain root is built for x68_64 (probably your host), whereas you'd need it to be built for the target (i386 simulator).
>
> Correct, that's exactly what's happening here. Since this bot is only running `check-debuginfo` and `check-lldb`, would it make sense to stop building libcxx altogether (that is drop `libcxx;libcxxabi` from `LLVM_ENABLE_PROJECTS`)? That way the compiler should pick up the one inside the sysroot since that's the only one available.
No, the bot is also meant to catch changes to libc++ breaking LLDB (or at least making sure we update the corresponding data formatters). I don't think that really matters for the simulator tests though. So if the toolchain takes precedence over `-L` too, how can I use the just-built compiler and make sure we continue to use the libc++ from the SDK?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D45639/new/
https://reviews.llvm.org/D45639
More information about the cfe-commits
mailing list