On 20 April 2017 at 19:42, Scott Smith wrote:
> Sorry, I take that back. I forgot to save the buffer that ran the test
> script. Oops :-(
>
> I get a number of errors that make me think it's missing libc++, which
> makes sense because I never installed it. However, I thought clang
> automatica
Sorry, I take that back. I forgot to save the buffer that ran the test
script. Oops :-(
I get a number of errors that make me think it's missing libc++, which
makes sense because I never installed it. However, I thought clang
automatically falls back to using gcc's libstdc++.
Failures include:
On Thu, Apr 20, 2017 at 6:47 AM, Pavel Labath wrote:
> 5. specifying gcc-4.8 instead of the locally compiled clang
>
> has most of the tests passing, with a handful of unexpected successes:
>>
>> UNEXPECTED SUCCESS: TestRegisterVariables.Register
>> VariableTestCase.test_and_run_command_dwarf
>>
On 20 April 2017 at 15:01, Tamas Berghammer wrote:
> AFAIK the Ubuntu 14.04 cmake builder runs tests using ToT clang (built on
> the build bot) as step test3 and test4 and it seems to be green so if you
> are seeing different result then I would expect it to be caused by a
> configuration differe
AFAIK the Ubuntu 14.04 cmake builder runs tests using ToT clang (built on
the build bot) as step test3 and test4 and it seems to be green so if you
are seeing different result then I would expect it to be caused by a
configuration difference between the setup the bot has and you have (or the
bot ru
On 19 April 2017 at 19:15, Scott Smith wrote:
> A combination of:
> 1. Updating to a known good release according to buildbot
> 2. using Ubuntu 14.04
> 3. compiling release using clang-4.0
>
I'd hope that the compiler used to build lldb does not matter. If you see
any differences due to this fact
A combination of:
1. Updating to a known good release according to buildbot
2. using Ubuntu 14.04
3. compiling release using clang-4.0
4. using the dotest command line that buildbot uses
5. specifying gcc-4.8 instead of the locally compiled clang
has most of the tests passing, with a handful of un
> On Apr 19, 2017, at 7:37 AM, Pavel Labath via lldb-dev
> wrote:
>
> It is on purpose, although whether that purpose is worthwhile is debatable...
>
> We chose to run release builds there so to align the bots closer to the
> binaries we release. Unfortunately, it does mean we run into situat
It is on purpose, although whether that purpose is worthwhile is
debatable...
We chose to run release builds there so to align the bots closer to the
binaries we release. Unfortunately, it does mean we run into situations
like these...
In any case, I have now a patch up for fixing one of the cras
Yeah I found the buildbot instance for lldb on Ubuntu 14.04, but it looks
like it is only running release builds. Is that on purpose?
On Wed, Apr 19, 2017 at 3:59 AM, Pavel Labath wrote:
> It looks like we are triggering an assert in llvm on a debug build. I'll
> try to track this down ASAP.
>
>
It looks like we are triggering an assert in llvm on a debug build. I'll
try to track this down ASAP.
On 18 April 2017 at 21:24, Scott Smith via lldb-dev wrote:
> I'm trying to make sure some of my changes don't break lldb tests, but I'm
> having trouble getting a clean run even with a plain ch
I'm trying to make sure some of my changes don't break lldb tests, but I'm
having trouble getting a clean run even with a plain checkout. I've tried
the latest head of master, as well as release_40. I'm running Ubuntu
16.04/amd64. I built with:
cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=Debug
ni
12 matches
Mail list logo
