Running dotnet coreclr on alpine about docker-alpine

[obadz]

Does anyone have the content of that gist? Looks like @jasonwilliams200OK has deleted his account..

[saberone]

I'd suggest to investigate whether this : https://pkgs.alpinelinux.org/package/edge/testing/x86_64/lldb makes debugging available.

My personal goals is to be able to debug a dotnetcore application within the container with Visual Studio Code. With the lightness of Alpine Linux.

@saberone, CorecLR master now builds on Alpine Linux, lldb was one of the thing we ported during the process. See https://github.com/dotnet/coreclr/issues/917#issuecomment-225368723

To build CoreCLR on Alpine yourself, you may follow these steps: https://gist.github.com/jasonwilliams200OK/7d6f5594d3bf697a27c9c1036d349fce.

[helloitszak]

Had an hours worth of playing around with this. But fundamentally this is an issue for alpine/CoreCLR, not really your guys' container. Perhaps you might be able to give some insight though.

dotnet/coreclr#917 is related. Though is concern seems mostly about running CoreCLR without MMUs

At least libunwind requires execinfo.h which is not available under musl.
Haven't checked the CoreCLR codebase itself to see if it requires anything glibc specific. Never built anything under clang/llvm before, so I don't know if the libc stuff.

I found a "guide" to building unwind on musl, but it's quite out of date and had no luck with it.
http://wiki.musl-libc.org/wiki/BuildingLLVM#Build_libunwind

LLVM and Clang should be a piece of cake as they are already on apk. lldb is not on apk, but it's not REQUIRED to run CoreCLR, despite it being listed on the requirements list. The BSD compile process seems to just ignore it.

Perhaps a static compilation might work, but that'd produce some pretty fat binaries.

[luisrudge]

Any thoughts on this?

[andyshinn]

Is coreclr something that requires mono? It probably just needs a package built for Alpine. This is sort of out of scope for this repository. But I'll take a quick crack at it when I have a spare moment.

[luisrudge]

No. CoreCLR is it's own thing. It's actually an optimized and xplat .NET framework by Microsoft. The build instructions are in the first comment. BUt I guess there are so many things missing that maybe it's not possible at the time. :(

[andyshinn]

LLDB may not be required to run CoreCLR. But it is complaining about it on build. I'd check out the APKBUILD file for LLVM and contact then maintainers or post to the Alpine mailing list about building LLDB and the corresponding -dev package in the LLVM package. This would be the next step to getting CoreCLR building.

We can re-open this issue after LLDB exists in Alpine if you need more help from there.

Hello, @benpye has ported libunwind on Alpine https://pkgs.alpinelinux.org/package/testing/x86_64/libunwind. I have ported CoreFX - https://github.com/dotnet/corefx/pulls?q=is%3Apr+alpine+is%3Aclosed (which is the .NET base class library BCL) and requires runtime (CoreCLR) to function. Progress on CoreCLR on Alpine is still underway dotnet/coreclr#2262 and need community help.

---

About LLDB in relation to CoreCLR:

LLDB is not the pre-requisite of building CoreCLR, we can disable it in cmake config (as Ben has done in WIP PR) but would certainly help if someone port it: https://bugs.alpinelinux.org/issues/4966. I tried taking a stab at it. LLDB requires LLVM sources to build. To get exact source of LLVM, I cloned aports repo, checking out to the release commit of llvm (from https://pkgs.alpinelinux.org/package/main/x86_64/llvm), configured the aports (applying make patches) and then cmake LLDB. There were couple of clang warnings about unused-vairables in LLVM code, so I passed -Wno-unusedXX flags to clang but then some errors struck. So couldn't get passed LLVM errors to build LLDB.

Would be very helpful if someone can take help us out here; but LLDB will only add debugging functionality to CoreCLR, but certainly not a blocker to get the runtime functional for mass usage.

---

CoreCLR without LLDB:

Ben's PR is mostly highlighting the potential areas which need pondering, i.e getting __GNUC_VA_LIST to work and having better feature detection in CMake. Although the PR conversation (what was supposed to provide feedback on specific issue, instead of code review on tentative patch) got sidetracked (sorry about that Ben!), there is still work that can be done to deliver CoreCLR without LLDB on Alpine Linux and get all the glorious managed .NET assemblies of CoreFX functional.

---

Help wanted (current known blocker):

• __GNUC_VA_LIST on Alpine Linux or some subsitute to fill the void.

Feedback which we discovered for musl-libc, which we hope will be routed to concerned parties and fixed upstream (although we have silent the potential warning):

• https://github.com/dotnet/corefx/issues/6312

[stephenrjohnson]

Has there been any movement on this?

@stephenrjohnson, as far as i can tell, lldb is still not available on Alpine https://bugs.alpinelinux.org/issues/4966.

[benpye]

I would suggest removing the lldb dependency for Alpine, especially in the
context of docker. It's only the debug plugin that cannot be built.

On Thu, 2 Jun 2016, 13:03 Peter Jas, [email protected] wrote:

@stephenrjohnson https://github.com/stephenrjohnson, as far as i can
tell, lldb is still not available on Alpine
https://bugs.alpinelinux.org/issues/4966.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAbA_26Yo-kzjSzZYCziP4i6iB-ulDETks5qHsaLgaJpZM4Ej1ZM
.

Docker for official dotnet 2.1 (the upcoming release) is available for Alpine including many others: https://hub.docker.com/r/microsoft/dotnet

docker run -it microsoft/dotnet:2.1-sdk-alpine

this is dotnet runtime with SDK. After hitting enter, when you get into the container:

dotnet new console -n test
cd test
dotnet run

# 'Hello World!' is printed

Also there is dotnet-docker repo with source code for each available docker: github.com/dotnet/dotnet-docker