labath added a comment.
The overall logic and the include and library paths make sense to me. The rpath
thingy will not work on windows as it (afaik) has no equivalent feature (it has
the equivalent of (DY)LD_LIBRARY_PATH though). Do you just want to make that
unsupported. I don't think we're running libc++ tests on windows right now, so
I guess nothing will be lost there, though we will need to implement this
differently at some point.
And I suppose that the plan is to not use this path at all for remote runs (?)
That makes sense to me, since the build tree is unlikely to contain a usable
libc++ (unless the remote machine has the same architecture).
================
Comment at: lldb/packages/Python/lldbsuite/test/dotest.py:284
+ configuration.hermetic_libxxx = args.hermetic_libcxx
+
----------------
libcxx
================
Comment at: lldb/packages/Python/lldbsuite/test/make/Makefile.rules:394
else
- CXXFLAGS += -stdlib=libc++
- LDFLAGS += -stdlib=libc++
- endif
- ifneq (,$(filter $(OS), FreeBSD Linux NetBSD))
- ifneq (,$(LLVM_LIBS_DIR))
- LDFLAGS += -Wl,-rpath,$(LLVM_LIBS_DIR)
+ CXXFLAGS += -DLLDB_USING_LIBCPP
+ ifeq "$(OS)" "Android"
----------------
I think this should be set in the "hermetic" case as well (or, given that it is
unused, we might delete it completely).
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
