From @NinoFloris on June 12, 2017 22:3

@gkhanna79 @piotrpMSFT Would you perhaps have experience with this for OSX?

From @gkhanna79 on June 12, 2017 22:53

@mikem8361 @lt72 should be able to help.

From @mikem8361 on June 12, 2017 22:58

"libsos.dylib" isn't the lldb plugin to load; it is loaded by the lldb plugin (libsosplugin.dylib). For OS X because of signing issues, etc. you have to first build a version of lldb locally and then build the libsosplugin in the coreclr repo against that.

Some directions:

https://github.com/mikem8361/coreclr/blob/master/Documentation/building/buildinglldb.md

From @NinoFloris on June 12, 2017 23:42

Noess, I was hoping to avoid all these native build shenanigans. Is that really the only way? Could this not be made a bit easier? I reckon there are quite a few dotnet core people that work on OSX.

Would a brew formula be an option to abstract the hard and error prone work to build and setup SOS?

(I could devote some of my time to that, if that sounds like something that could work)

From @mikem8361 on June 13, 2017 23:58

There are two parts of SOS on Linux and OSX: the lldb plugin (libsosplugin.dylib) and the actual SOS code (libsos.dylib). The lldb plugin needs to be built against the version lldb you are going to use. The libsos.dylib version needs to match the coreclr you are running. The problem is that the includes/libs (LLDB.h, etc. and liblldb.dylib) needed to build the plugin for the default lldb (lldb-370.0.42 on Sierra) on Mac don’t seem to exist anywhere.

The only solution we have come up with for now is to clone and build lldb which results in the includes/libs needed to build the plugin. Those includes/libs don’t match the default lldb because it isn’t clear what build of lldb apple ships. The other problem is the lldb must be built locally with a signing certificate generated by you. The lldb you build or the one I build won’t work on any other machine.

There might be a way to create a cert that could be installed on a machine and package (via brew) lldb and the plugin built against that cert. I don’t know enough about the signing process to know if that would work or the time to research it.

The other solution is to find the matching LLDB.h, etc and lib files for the lldb installed by default (i.e. lldb-370.0.42 on Sierra). I could never figure this one out either.

From @NinoFloris on June 14, 2017 1:19

I think they are actually building from this repo https://github.com/apple/swift-lldb, and it is quite likely to be the build tagged with https://github.com/apple/swift-lldb/releases/tag/swift-3.1-RELEASE

As my terminal reports the exact string format as changed in that commit when I do lldb --version

About brew and the cert, letting the formula build it all locally is already miles better than having to do all that manually, it's still a brew install for anyone that wants to quickly get going, the build is just going to take some time.

What is the CLI issue here? I will confess that I don't quite follow this thread. If this is not a CLI problem, and it does not look to be, I would like to close this issue.

From @mikem8361 on June 15, 2017 5:28

The coreclr issue is that the lldb part of the SOS isn't being provided for OS X for all the reason above. This makes it difficult to use lldb/SOS against a CLI/managed app on OS X.

Should this be moved to the coreclr repo then?

From @mikem8361 on June 15, 2017 8:18

Yes.

Just wanted to note, after having built lldb, you need to build this repo by yourself to get a libsosplugin.dylib on your macOS. Since it's not provided along with published .net core runtime.

Issue moved to dotnet/diagnostics dotnet/runtime#3873 via ZenHub