[Lldb-commits] [PATCH] D111981: [lldb] Fix missing dependency on libc++ from LLDB test suite on non-Darwin platforms
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Oct 18 23:56:08 PDT 2021
labath added a comment.
In D111981#3071414 <https://reviews.llvm.org/D111981#3071414>, @dblaikie wrote:
> Oh, mostly my point was "the output changes after I explicitly run `ninja cxx`" so it looks like the dependency didn't fully address the build consistency issue, regardless of what the failure actually is?
This looks like a classic example of the reason why `if(TARGET FOO)` is discouraged in cmake.
The top level cmake file looks like this:
add_subdirectory(projects) # libcxx IN LLVM_ENABLE_PROJECTS processed here
if( LLVM_INCLUDE_TOOLS )
add_subdirectory(tools) # lldb IN LLVM_ENABLE_PROJECTS processed here
endif()
if( LLVM_INCLUDE_RUNTIMES )
add_subdirectory(runtimes) # libcxx in LLVM_ENABLE_RUNTIMES processed here
endif()
If one enables libcxx via LLVM_ENABLE_PROJECTS (which is I guess what the apple folks are using) then all is fine, as the cxx target will be defined by the time we get to lldb. OTOH, if one uses LLVM_ENABLE_RUNTIMES, then the check will return false (and not add the dependency), even though the target will be defined afterwards (and will be found by clang at runtime).
I think (but I haven't verified) that this could be fixed by replacing `TARGET cxx` with `libcxx IN LLVM_ENABLE_PROJECTS OR libcxx IN LLVM_ENABLE_RUNTIMES`.
>> Can you apply https://reviews.llvm.org/D111978 and see what the error output with that patch is? It should give you exit status/description and stderr.
>
> Sure, I'll give that a go (was going to test it once it was submitted), but emulating something similar to the test, by debugging the binary directly:
>
> $ ./bin/lldb ./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out
> (lldb) target create "./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out"
> Current executable set to '/usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out' (x86_64).
> (lldb) start
> error: 'start' is not a valid command.
> (lldb) r
> warning: (x86_64) /lib/x86_64-linux-gnu/ld-2.32.so Unable to initialize decompressor for section '.debug_abbrev': zlib is not available
> warning: (x86_64) /lib/x86_64-linux-gnu/ld-2.32.so Unable to initialize decompressor for section '.debug_info': zlib is not available
> Process 3723631 launched: '/usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out' (x86_64)
> warning: (x86_64) /lib/x86_64-linux-gnu/ld-2.32.so Unable to initialize decompressor for section '.debug_aranges': zlib is not available
> warning: (x86_64) /lib64/ld-linux-x86-64.so.2 Unable to initialize decompressor for section '.debug_abbrev': zlib is not available
> warning: (x86_64) /lib64/ld-linux-x86-64.so.2 Unable to initialize decompressor for section '.debug_info': zlib is not available
> /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/map/TestDataFormatterLibccMap.test_with_run_command_dwarf/a.out: error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory
>
> I don't /think/ there's any reason (given the current Cmake configuration/code/etc) that the binary should be able to find libc++.so.1? In the libc++ tests (not the lldb libc++ tests, but the libc++ libc++ tests) they specify -rpath when compiling libc++ binaries against the just-built libc++ so they'll find the just-built libc++.so. I don't see anything like that in the lldb libc++ tests/build.
Yeah, we'd have to take some positive action to make that hapen.
I think the best way to go about that is to call `registerSharedLibrariesWithTarget` under the right circumstances. That would ensure ((DY)LD_LIBRARY_)PATH is set, and also copy the library for remote tests. I'm just not entirely sure what are "the right circumstances".
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D111981/new/
https://reviews.llvm.org/D111981
More information about the lldb-commits
mailing list