[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]

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