On Tue, Aug 25, 2015 at 5:40 AM, Tamas Berghammer tbergham...@google.com
wrote:
Going back to the original question I think you have more test failures
then expected. As Chaoren mentioned all TestDataFormatterLibc* tests are
failing because of a missing dependency,
Thanks, Tamas. I'm going
So specifying CC=/usr/bin/gcc CXX=/usr/bin/g++ cmake -GNinja ...
did the trick for getting rid of the libc++ issues. I think I may try to
see if we can get those tests to make a run-time check to see if the
inferior is linked against libc++, and if not, to skip it. We can have
lldb do it by
On Tue, Aug 25, 2015 at 04:39:14PM -0700, Todd Fiala wrote:
I may dig into that if nobody beats me to it. I did the original
multiprocessing work on dosep ~1.5 years ago and it may be doing something
goofy.
Cool! It would be awesome if you could have a look - I've been meaning to dig
It is fairly common practice (at least it is for me) when figuring out why a
test failed, or adding to a test case, or when looking for a good example file
to poke at, etc, to go to some relevant test directory, do a make then poke
around a bunch. I don't generally remember to clean when I'm
Sorry, kernel bug is probably the wrong word. It's a problem specific to
WMware.
On Tue, Aug 25, 2015 at 4:25 PM, Chaoren Lin chaor...@google.com wrote:
Are you running VMware by any chance? TestStepOverWatchpoint fails on
VMware because of a kernel bug.
On Tue, Aug 25, 2015 at 4:17 PM, Todd
While looking into a Windows-specific issue involving TestTargetAPI.py, I
noticed that we are building the exact same executable many times. Every
single test has a line such as self.buildDwarf() or self.buildDsym().
Those functions will first run make clean and then run make, essentially