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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
