labath added a comment. I'm afraid this will not work on systems which do not default to libc++ (which includes at least linux and windows), because `-stdlib=libc++` is not "equivalent" to `-nostdlib++ -lc++` -- the former changes the include paths to use libc++, while the latter doesn't. And, for most of the things that we do here, headers are more important than the library itself.
If the goal here is to preclude any possibility of picking up a different library (it's not clear to me what kind of situation you're referring to in the description), then the most principled approach would be to also use `-nostdinc++` and manually add the appropriate include paths. One nice property of that is that it would work with compilers (gcc) which do not understand the `-stdlib` flag. The simple solution would be to use the `-stdlib=libc++ -nostdlib++` as a combo, but I am not sure if that would solve what it is supposed to solve (as it still relies on clang to autodetect the header path). Another thing to consider is that historically (back when we were running the tests against the system compiler by default), the `USE_LIBCPP` flag meant "use the system libc++" (or rather, the default library of the compiler in use). Now we use the in-tree compiler (by default), but our libc++ story is not so clear, as it mostly relies on clang. If the build contains libc++ then we will use that (and sometimes fail due to incorrect usage). If it doesn't, but there's a libc++ on the system somewhere, then we will use that one (and be non-hermetic). Otherwise, we will skip tests which depend on this (and the skipping code uses its own logic, which is not touched here). Overall, I think it makes sense to use libc++ when we have it available. I am not so sure about the other modes. While I think it would be nice to support running the tests against a random c++ library (similar to how we do it for compilers), I don't think we need to support it unless there someone actively interested in running it. I do think we should support a mode where we don't have a libc++ in the build tree, but I'd be fine if that just causes all of the relevant tests to be skipped. The thing where that gets interesting is with remote tests. Unlike system libc++, I think we have people (including myself, to some extent) whose job is to make sure those work. Right now, we don't make any special effort to copy the c++ library to the remote system. If it works, it works because the system already has a compatible c++ library lying around. The reason these two are related is that the system libc++ is more likely to be present on a remote system than the one we just built. Messing with the way use libc++ may break some of the remote use cases, so it might be good to take some position on that. Do we not support that? Do we expect the user to make sure the libc++ is on the system already? Do we expect the user to link libc++ statically (I think that's what happens in all of our use cases)? I realize this isn't very helpful, but I'm trying to explain why I fear this may be more complicated than it may seem at first. Maybe it is not necessary to answer all of these questions for the problem at hand, but these are the questions that have stopped me from doing anything in this area in the past. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129166/new/ https://reviews.llvm.org/D129166 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
