There were 2 changes made this week that broke both the cmake and one that
broke the Makefile builds. I checked in fixes for the cmake build, but no
one has done similar for the Makefile build (as far as I've noticed).
(Notably, there's no Makefile support for
source/Plugins/ExpressionParser/Clang
https://llvm.org/bugs/show_bug.cgi?id=15854
Siva Chandra changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Hi all,
TL;DR: if you call dosep.py directly, you'll need to modify your flow to
call dotest.py.
*Details:*
*dotest.py now runs in parallel test runner mode by default*
Starting with lldb svn revision 246794, if you run buildbots or testbots
and you directly called dosep.py as a build step, you
We forced a clean build because it wasn’t picking up an enum change that
affected the swig python bindings, and the objective c problem popped up.
I’ve built with cmake on that machine, and it worked. I think the right answer
is switch to cmake.
--
Qualcomm Innovation Center, Inc.
The Q
Hi,
Is it possible to convert a bitcode file with same target (Ex. ARM) with
sub arch (armv7 or armv7s) into another bitcode or native code format(Ex.
ARM with armv8 or arm64) ?
I am also assuming that one Arch(ARM) to another Arch(X86) conversion not
possible.(correct me if I am wrong)
This que
Can you change it to CMake instead of configure? I know that's not what
you want to hear, but the configure build is on its way out, so you're
going to have to do this at some point anyway.
On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I haven't seen
I haven't seen that one myself. Are you still seeing it?
Is it possible the buildbot's commands are possibly using older/stale
object files? Is distcc/ccache involved? Does the build force a clean
build? If not, does the issue go away on a clean build? Is it
configure-based or cmake based?
J
https://llvm.org/bugs/show_bug.cgi?id=19310
lab...@google.com changed:
What|Removed |Added
Assignee|lldb-dev@lists.llvm.org |lab...@google.com
--
You are receiving this
https://llvm.org/bugs/show_bug.cgi?id=24693
Bug ID: 24693
Summary: liblldb.so link failure due to missing -ltinfo flag on
systems with split ncurses/tinfo
Product: lldb
Version: 3.7
Hardware: PC
OS: Linux
https://llvm.org/bugs/show_bug.cgi?id=24691
Bug ID: 24691
Summary: Assertion failure in clang in TestFormatters.py
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
+1 for the naming idea. It sounds like the a more reliable solution
than crawling backtraces to me.
pl
On 3 September 2015 at 06:32, Todd Fiala via lldb-dev
wrote:
> I think the thread naming is a reasonable way to go.
>
>> 1) Linux and MacOSX inferiors can use pthread_setname_np
>> 2) FreeBSD i
11 matches
Mail list logo
