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`.
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. Cheers, Louis > On Oct 25, 2021, at 13:57, David Blaikie <dblai...@gmail.com> wrote: > > +Louis Dionne <mailto:ldio...@apple.com> - 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... > > On Wed, Oct 20, 2021 at 1:57 PM David Blaikie <dblai...@gmail.com > <mailto:dblai...@gmail.com>> wrote: > On Tue, Oct 19, 2021 at 4:55 PM David Blaikie <dblai...@gmail.com > <mailto:dblai...@gmail.com>> wrote: > On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann <teempe...@gmail.com > <mailto:teempe...@gmail.com>> wrote: > Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT > workaround *should* still work. > > 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: > https://groups.google.com/g/llvm-dev/c/tpuLxk_ipLw > <https://groups.google.com/g/llvm-dev/c/tpuLxk_ipLw> > > Yep, it does work with LLVM_ENABLE_PROJECT rather than LLVM_ENABLE_RUNTIME. > > Specifically the test binary is linked with an rpath to the just-built lib > directory that ensures the just-built libc++.so is found: > > /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" > > 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 > > Looks like this rpath setting happens here: (changing this to a junk argument > causes the test to fail to build as expected) > https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400 > > <https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400> > > And it gets the LLVM_LIBS_DIR from here: > https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163 > > <https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163> > > 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? ( > https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424 > > <https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424> > ) 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?) > > 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): > $ git diff > diff --git lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in/> > lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in/> > index 987078a53edb..e327429b7ff9 100644 > --- lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in/> > +++ lldb/test/API/lit.site.cfg.py.in <http://lit.site.cfg.py.in/> > @@ -3,7 +3,7 @@ > config.llvm_src_root = "@LLVM_SOURCE_DIR@" > config.llvm_obj_root = "@LLVM_BINARY_DIR@" > config.llvm_tools_dir = "@LLVM_TOOLS_DIR@" > -config.llvm_libs_dir = "@LLVM_LIBS_DIR@" > +config.llvm_libs_dir = "@LLVM_LIBS_DIR@/@LLVM_DEFAULT_TARGET_TRIPLE@" > config.llvm_shlib_dir = "@SHLIBDIR@" > config.llvm_build_mode = "@LLVM_BUILD_MODE@" > config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@" > > Thoughts?
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
