Some API test failures are really opaque/could be improved

That makes it sound like we have an lldb that only works with one of the libcxx layouts, and not older ones. That doesn’t seem right, shouldn’t we support both versions?

I wish we could do that but AFAIK, there is no way to know which version of libcxx (and thus which layout) we are using … IIUC, the version the user could be using on their system could be totally different from the one lldb builds against

I think gdb manages this, though? Probably partly by shipping the pretty printer with the standard library, instead of with the debugger?

Though perhaps the question of how to support different libc++ layouts needs a separate thread from this one?

I’d really like to focus on how to get the test suite passing reliably - and, I think, generally using the just-built clang+libcxx (it’s already using the just-built clang, and it looks like it’s intended to use the just-built libcxx but fails at the last hurdle loading that shared library in the program execution)

@JDevlieghere hmm, I wonder what’s happening in your situation - that’s on MacOS, yeah? Where there’s no per target runtime directory, so far as I know. What’s in your ./lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/vector/TestDataFormatterLibcxxVector.test_with_run_command_dwarf/Failure.log ?

So, it seems for now if I want to have a clean test run in lldb on Linux I need to disable libc++ building in that tree… so I’ll do that. :confused: