Hello lldb-dev,
We've just updated our mac buildbot to 10.13.1 (from 10.10.x), and
we're having trouble with the lldb test suite. All of the tests are
failing with the following error:
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Python/lldbsuite/test/crashinfo.c:15:10:
fatal err
On a somewhat tangential note:
Is anyone actually using this crashinfo hook? It looks like this could
be useful in the old dotest days, when we were running all of the
tests in a single python process, but now with the parallel test
runner spawning a new process for each test file and with piping
Xcode and general development on macOS has moved from using headers in the base
OS (/System/Library/Frameworks…) for building programs to using SDK’s to
contain all the header files. The installed tools will know how to find the
correct SDK.
On a clean install of 10.13 there are no headers a
Thanks for the reply, Jim.
As far as I can tell, we already have Xcode on that machine (I only
have shell access there).
$ xcodebuild -version
Xcode 9.1
Build version 9B55
$ xcode-select -version
xcode-select version 2349.
BTW, this is the list of Python.h files on that machine:
/Library/Develop
The build should be finding the version in the SDK within Xcode. I do have the
CommandLineTools directory on my system, but it doesn’t have an SDK directory
in it. I wonder if that is causing the problem?
One thing to check, do:
$ xcrun -find clang
Does that find clang in the DeveloperTool
Right, after learning way more than I ever wanted to know about xcrun,
I think I see the issue. When running with empty SDKROOT variable,
xcrun sets SDKROOT to "/" when running clang:
$ SDKROOT= xcrun --no-cache --log --verbose clang
/Users/lldb_build/lldbSlave/buildDir/llvm/tools/lldb/packages/Pyt
Pavel, I happened to hit this.
I'm not sure how you worked around, as I tried to export
SDKROOT=macosx but that didn't work for me.
Do you have a patch or a series of commands I can run?
Thanks,
--
Davide
On Thu, Nov 16, 2017 at 4:25 AM, Pavel Labath via lldb-dev
wrote:
> Right, after learning
In test/testcases/configuration.py:47, change "SDKROOT=" to "SDKROOT=macosx".
I did not put this out for review (yet) mainly because I was not sure
whether this affects only our buildbot (which was updated from some
ancient version straight to 10.13, so it could be something introduced
by the upgr
I also just hit this and apparently this is an intentional behavior of xcrun.
Note that this only affects systems that have the so-called command line tools
installed (this is what you get when you install the command line tools without
installing Xcode).
When the command line tools are install
On 18 December 2017 at 23:51, Adrian Prantl wrote:
> I also just hit this and apparently this is an intentional behavior of xcrun.
>
> Note that this only affects systems that have the so-called command line
> tools installed (this is what you get when you install the command line tools
> withou
Jason probably knows about the crash hook.
On Tue, Dec 19, 2017 at 4:24 AM, Pavel Labath wrote:
> On 18 December 2017 at 23:51, Adrian Prantl wrote:
>> I also just hit this and apparently this is an intentional behavior of xcrun.
>>
>> Note that this only affects systems that have the so-called
> On Dec 19, 2017, at 4:24 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 18 December 2017 at 23:51, Adrian Prantl wrote:
>> I also just hit this and apparently this is an intentional behavior of xcrun.
>>
>> Note that this only affects systems that have the so-called command line
>> tools in
On 19 December 2017 at 18:06, Greg Clayton wrote:
>
> The crash hook is needed since ReportCrash on MacOS knows how to dig up a
> crash log line for each shared library that is currently loaded in a process
> when it generates a crash report. There are settings that we can enable to
> enable al
This is actually using the same mechanism that Greg was describing, but through
a separate route.
With the crashinfo mechanism in place, if a test crashes the crash log will
show whatever test was being run at the time of the crash. This was pretty
useful when we were running the testsuite i
On 2 January 2018 at 19:20, Jim Ingham wrote:
> This is actually using the same mechanism that Greg was describing, but
> through a separate route.
>
> With the crashinfo mechanism in place, if a test crashes the crash log will
> show whatever test was being run at the time of the crash. This w
15 matches
Mail list logo
