<div dir="ltr">I haven't made any further progress on it - I think the actual git diff I posted, changing config.llvm_libs_dir wouldn't quite be shippable as-is, because it's only correct to add the "/@LLVM_DEFAULT_TARGET_TRIPLE@" if the runtimes were built with <span style="color:rgb(80,0,80)">LLVM_ENABLE_PER_TARGET_RUNTIM</span><span style="color:rgb(80,0,80)">E_DIR ON (which is the default on Linux, but not on MacOS) - so some extra conditionality is needed, but I'm not sure of the best/right place to implement that.</span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 4, 2021 at 8:15 AM Raphael Isemann <<a href="mailto:teemperor@gmail.com">teemperor@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is someone currently working on fixing this? FWIW, I think David's<br>
change seems to go in the right direction (when I originally looked at<br>
this I also ended up on the wrong rpath but I thought it was some<br>
other code that set the wrong value. Didn't realize we have two places<br>
where this happens). I think David's diff is better than we currently<br>
have so maybe we should just turn this into a review?<br>
<br>
Am Di., 26. Okt. 2021 um 06:43 Uhr schrieb David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>>:<br>
><br>
> On Mon, Oct 25, 2021 at 1:28 PM Louis Dionne <<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>> wrote:<br>
>><br>
>> I believe the issue is probably not related so much to LLVM_ENABLE_PROJECTS vs LLVM_ENABLE_RUNTIMES, but rather to the fact that LLVM_ENABLE_RUNTIMES uses per-target runtime directories now (hasn't always been the case), which basically means that libc++ ends up in `<prefix>/lib/<target-triple>/libc++.so` instead of `<prefix>/lib/libc++.so`.<br>
><br>
><br>
> Ish, yes. It's a bug in LLVM_ENABLE_RUNTIMES that isn't present in LLVM_ENABLE_PROJECTS, so for now if I want to run the lldb pretty printer tests for libc++ on Linux it seems the only way I can is by using the deprecated functionality of libc++ in LLVM_ENABLE_PROJECTS.<br>
><br>
> Consider this a bug report (looks like a bug in the lldb CMake configuration, not in libc++'s build itself, but something to figure out if Linux lldb devs are going to use libc++ +.ENABLE_RUNTIMES path) on that deprecation?<br>
><br>
>><br>
>> I think you either want to specify the per-target library dir when running against libc++, or you want to disable that and use `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF` when configuring the runtimes. In all cases, you want to be using `LLVM_ENABLE_RUNTIMES` and not `LLVM_ENABLE_PROJECTS`, since the latter is deprecated now.<br>
><br>
><br>
> I didn't enable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR myself/in the root cmake config. It looks like it's hardcoded(?) into the ENABLE_RUNTIMES sub-build? <a href="https://github.com/llvm/llvm-project/blob/e5fb79b31424267704e9d2d9674089fd7316453e/llvm/runtimes/CMakeLists.txt#L76" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/e5fb79b31424267704e9d2d9674089fd7316453e/llvm/runtimes/CMakeLists.txt#L76</a> I'm not sure there's any way to override that from the root? And in any case I'd have thought the defaults would need to/be intended to work correctly on supported platforms?<br>
><br>
> So something in lldb's dir handling (maybe some general infrastructure in LLVM could use some improvement to provide an LLVM_RUNTIME_LIBS_DIR, or similar? that could then be used from other places - rather than libc++, for instance, creating that directory for itself based on LLVM_LIBS_DIR and LLVM_ENABLE_PER_TARGET_RUNTIME_DIR, etc) needs some fixes to support the current defaults/hardcoded modes on Linux?<br>
><br>
>><br>
>> Cheers,<br>
>> Louis<br>
>><br>
>> On Oct 25, 2021, at 13:57, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> +Louis Dionne - perhaps the libcxx and lldb folks would be interesting in finding a suitable way to address this issue, since currently either option (using libcxx in ENABLE_PROJECTS or using it in ENABLE_RUNTIMES) is incomplete - if I use ENABLE_RUNTIMES I get the libcxx testing run against the just-built clang and generally this is the "supported" configuration, but then some lldb tests fail because they can't find libcxx.so.1 (on Linux) - and using ENABLE_PROJECTS means not using the just-built clang for libcxx tests (so missing the libcxx breakages caused by my array name change) but do use the just-built libcxx in lldb tests and find failures there...<br>
>><br>
>> On Wed, Oct 20, 2021 at 1:57 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>>><br>
>>> On Tue, Oct 19, 2021 at 4:55 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>>>><br>
>>>> On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann <<a href="mailto:teemperor@gmail.com" target="_blank">teemperor@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT<br>
>>>>> workaround *should* still work.<br>
>>>><br>
>>>><br>
>>>> I'll give that a go (it's running at the moment) though I guess this is inconsistent with the direction libcxx is moving in for building, re: <a href="https://groups.google.com/g/llvm-dev/c/tpuLxk_ipLw" rel="noreferrer" target="_blank">https://groups.google.com/g/llvm-dev/c/tpuLxk_ipLw</a><br>
>>><br>
>>><br>
>>> Yep, it does work with LLVM_ENABLE_PROJECT rather than LLVM_ENABLE_RUNTIME.<br>
>>><br>
>>> Specifically the test binary is linked with an rpath to the just-built lib directory that ensures the just-built libc++.so is found:<br>
>>><br>
>>> /usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang main.o -g -O0 -fno-builtin -m64  -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make/../../../../../include -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/list -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make -include /usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make/test_common.h -fno-limit-debug-info  -gsplit-dwarf    -stdlib=libc++ -Wl,-rpath,/usr/local/google/home/blaikie/dev/llvm/build/release/./lib --driver-mode=g++ -o "a.out"<br>
>>><br>
>>> Oh, actually it passes the same rpath when using LLVM_ENABLE_RUNTIME, but the libc++.so.1 is in a different place: ./lib/x86_64-unknown-linux-gnu/libc++.so.1<br>
>>><br>
>>> Looks like this rpath setting happens here: (changing this to a junk argument causes the test to fail to build as expected)<br>
>>> <a href="https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400</a><br>
>>><br>
>>> And it gets the LLVM_LIBS_DIR from here: <a href="https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163</a><br>
>>><br>
>>> So maybe we need to pass down the default target triple too, since that seems to be how libc++ is deciding where to put the library? ( <a href="https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424</a> ) at least on non-apple :/ (or maybe there's some way to make the connection between the two less brittle - for libc++'s build to export some variable that lldb can use, or for LLVM to provide something for both to use?)<br>
>>><br>
>>> Yeah, applying this change does work for me, but wouldn't work on Apple for instance (where libcxx doesn't add the default target triple to the path):<br>
>>> $ git diff<br>
>>> diff --git lldb/test/API/<a href="http://lit.site.cfg.py.in" rel="noreferrer" target="_blank">lit.site.cfg.py.in</a> lldb/test/API/<a href="http://lit.site.cfg.py.in" rel="noreferrer" target="_blank">lit.site.cfg.py.in</a><br>
>>> index 987078a53edb..e327429b7ff9 100644<br>
>>> --- lldb/test/API/<a href="http://lit.site.cfg.py.in" rel="noreferrer" target="_blank">lit.site.cfg.py.in</a><br>
>>> +++ lldb/test/API/<a href="http://lit.site.cfg.py.in" rel="noreferrer" target="_blank">lit.site.cfg.py.in</a><br>
>>> @@ -3,7 +3,7 @@<br>
>>>  config.llvm_src_root = "@LLVM_SOURCE_DIR@"<br>
>>>  config.llvm_obj_root = "@LLVM_BINARY_DIR@"<br>
>>>  config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"<br>
>>> -config.llvm_libs_dir = "@LLVM_LIBS_DIR@"<br>
>>> +config.llvm_libs_dir = "@LLVM_LIBS_DIR@/@LLVM_DEFAULT_TARGET_TRIPLE@"<br>
>>>  config.llvm_shlib_dir = "@SHLIBDIR@"<br>
>>>  config.llvm_build_mode = "@LLVM_BUILD_MODE@"<br>
>>>  config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"<br>
>>><br>
>>> Thoughts?<br>
>><br>
>><br>
</blockquote></div>