Support Alpine Linux (inadvertently to conform with libc for embedded systems)

[ghost]

musl (for Alpine), μClibc (for Alpine and Lilblue) and Newlib (for AmigaOS, Cygwin and PlayStation Portable) are standard C library implementations for embedded systems, which don't include Memory Management Unit (MMU).

If .NET team has plans to target microcontrollers/embedded-systems with coreclr, please provide support for those platforms.

Note that static lib libnix is also available for AmigaOS: http://cahirwpz.users.sourceforge.net/libnix/Description.html#Description (or https://github.com/cahirwpz/m68k-amigaos-toolchain)

Here is a list of major C standard libraries implementations: http://en.wikipedia.org/wiki/C_standard_library#Implementations

[ghuntley]

coreclr on embeded? This will be an interesting discussion to follow.

@jasonwilliams200OK are you aware of the .NET micro-framework - http://www.netmf.com/gadgeteer/ which is open source and available on GitHub @ http://netmf.github.io/

[ghost]

That well be an interesting discussion to follow.

Indeed. :)

/cc @smaillet-ms your thoughts?

[helloitszak]

I've been trying to get CoreCLR to build on Alpine and am stuck trying to compile libunwind. Seems that doesn't play nice with musl, specifically it doesn't have execinfo.h. Haven't looked much into any workarounds.

My goal is to eventually see if I can get ASP.NET vNext running on here, as Alpine is great for super lightweight Docker images (https://github.com/gliderlabs/docker-alpine)

[luisrudge]

Running on alpine would be awesome, since the docker image is very tiny!

[ghost]

Update: I have upstreamed all the local patches for Alpine Linux, one of the smallest Linux distro (~80 MBs ISO) that relies on musl-libc. It builds 99% of the CoreCLR without LLDB and event tracing (LIBLLTNG) support at the moment.

PRs: dotnet/coreclr#5726, dotnet/coreclr#5727, dotnet/coreclr#5728, dotnet/coreclr#5729, dotnet/coreclr#5730, dotnet/coreclr#5731.

This work is based on @benpye's original PR dotnet/coreclr#2262.

[smaillet-ms]

This is definitely interesting work. It is important to point out to those who may be following from the NETMF realms that this is NOT NETMF, but rather a port of CoreCLR to this platform. The discussion here is available due to common interests and a bit of high level overlap (embedded and .NET)

[ghost]

All the above mentioned PRs are merged.

Result is 💯 %

Repo successfully built.
Product binaries are available at /root/coreclr/bin/Product/Linux.x64.Debug
alp:~/coreclr#

As of this moment, CoreCLR (without lldbplugin) and CoreFX native both build on Alpine Linux. ⚡

Once lldb package is made available (i.e. very soon), I will rebuild CoreCLR and CoreFX native and post the test results with steps-by-step gist notes on how to build these from scratch installation here.

FYI: @barthalion, @benpye, @ellismg

[ghost]

Thanks to @barthalion for porting LLDB to Alpine Linux: https://pkgs.alpinelinux.org/packages?name=lldb. 🎉 ⭐

Now CoreCLR master builds on Alpine with lldbplugin (without missing anything).

Running the PAL suites revealed 12 failures: https://github.com/dotnet/coreclr/issues/5872.

Will run the managed test suite once PAL suite failures are sorted out.

[benpye]

👍 for getting this working!

[ghost]

With dotnet/coreclr#5872 closed, these are the final steps to build CoreCLR on Alpine Linux: https://gist.github.com/jasonwilliams200OK/7d6f5594d3bf697a27c9c1036d349fce and running the PAL tests. Note that CoreFX native also builds on Alpine. Now the verification (running full managed assemblies tests suite) and packaging parts are remaining.

While ISO is 87MB with still lots of auxiliary stuff bundled in, the minimal Alpine is just 5MB in size (aka slimmest Linux with smallest footprints) used by docker: https://hub.docker.com/_/alpine/:/ (see description) .. the next in line is TinyCore Linux, which is 11 MB in size, but depends on glibc (i was trying to build working clang38 on it but Alpine is already 2x slimmer than TC 😉 ) ..

For packaging, would be really nice to get someone from dotnet team to provide RID for Alpine Linux and APKBUILD script in dotnet/core-setup repo so we can build that project on Alpine... (we can help with APKBUILD script but please unblock us on core-setup)

Reference: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference
Examples: https://github.com/alpinelinux/aports/search?q=filename:apkbuild

cc: @jkotas, @ericstj, can Alpine get special love for dotnet core v1.0-RTM? long shot, but hopefully not impossible! 😊

[jkotas]

@jasonwilliams200OK v1.0-RTM is out the door. It would be for the update that comes next.

@joshfree @Petermarcu How can we get started on adding Alpine Linux to the list of the officially supported distros?

[ghost]

@jkotas, yup but the distros packaging systems can still get v1.0 at any point. For example, lldb38 was released couple of months back but aports (Alpine packaging sys) got it 9 days ago. :)

[Petermarcu]

Is the key blocker right now the RID for Alpine?

[Petermarcu]

In other words, an entry here... https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json

@jasonwilliams200OK you said please unblock you on core-setup. Is the RID issue whats blocking you?

[ericstj]

Folks can ammend the RID graph in their own package to try things out; any package with a runtime.json will get merged into the graph. We shouldn't be defining a RID compatibility relationship in the central MS.NETCore.Platforms until we have a chance to assess the compatibility of the distro with others/versions. That's ok to do in prerelease so long as we test it out and vet it before shipping stable.

[ericstj]

Read through this a bit more and here are the two options I see:

1. Build new packages that add Alpine to NETCore1.0. These can be done entirely on the side as I suggested above.
2. Add alpine to master for CoreFx/CoreCLR. These wouldn't be using 1.0 RTM bits but could be added by modifying the existing packages. We'd probably do this anyway if we expect to make it an officially supported distro.

To get the RID added please open an issue in CoreFx and spec what the Identifier should be and how it relates to existing ones and I can add it.

If folks want to understand the work behind adding support to 1.0 on the side I can elaborate on that.

/cc @schellap for core-setup. I believe @jasonwilliams200OK needs our help to create a build script.

[MihaMarkic]

Supporting mentioned OSes would be really great. Thumbs up.

[ghost]

@Petermarcu, @ericstj,

RID is something which is required whenever we try to build anything beyond CoreCLR / CoreFX: i.e. muxer (core-setup), or else the build script assumes platform to be Ubuntu. That is why i mentioned RID.

To build functional .NET Core on any operating system which Microsoft will care about in future or not, what steps need to be taken? Here is my understanding how someone in OSS land can try building .NET core for their distro:

• CoreCLR should build on the desired platform and all PAL tests pass. If there are any patches required, send pull requests.
• CoreFX should build and all managed assembly tests pass. If there are any patches required, send pull requests.

After that we are lost because:

• CLI does not "just build on any platform". Cross-compilation is not supported?
• CLI depends on core-setup. Core-setup requires dotnet muxer to build dotnet muxer (AFAICT) like roslyn requires csc to build csc.

If you can guide us how to build muxer by ourselves on the target platform or cross-compile from Ubuntu/Fedora for example, then we can build and validate everything in ports repos (aports, pkgsrc, portage, xbps etc.). For CoreFX assemblies which require platform specific native shims, we would need to publish those platform-specific partial assemblies to nuget as well.

@ericstj, at the moment, nuget and coreclr installers are identified as set of three segments:

<productName>-<operatingSystemNameOrFamily>-<operatingSystemArchitecture>

what is missing from this equation in cruntime identifier: glibc, musl, uclibc, dietlibs etc. against which the native compilation transpired. Gentoo and VoidLinux are examples which support multiple libc (in separate SKUs; in one install there is always one main libc which could be any one of the known variants).

One way to tackle it is by introducing another segment to identifier for libc name. And if that segment is missing, consider it glibc for non-windows. Something like <libc_dietlibc>, <libc_musl-libc>, <libc_uclibc>.

[jkotas]

One way to tackle it is by introducing another segment to identifier for libc name

I do not think that replicating all nuances of platform-specific native code packaging in nuget is a path to success. I think we need to have an option to distribute and acquire the unmanaged parts via the platform-specific package manager:

• System.*.Native.so would be acquired via build from source, apt-get and friends, etc
• The managed code in platform-specific corefx nuget packages would be good accross all Linux distros as long as you got System.Native.*.so required by the nuget packages to the box.

It is not that different from where we are today. You need to get the unmanaged dependencies like icu or openssl via platform-specific package manager already anyway. This would push the boundary a bit higher - to match where the boundary between managed and unmanaged code actually us.

The same strategy can also be used to make corefx packages that depend on System.*.Native shims to work on mono, discussed in https://github.com/dotnet/corefx/issues/9012#issuecomment-229448951

[ghost]

System.*.Native.so would be acquired via build from source, apt-get and friends, etc

Meaning the recommended way for platform package manager is give the experience like: tce-install netcore to get .NET Core package on TinyCore which would include version-specific:

• Everything CoreCLR
• All System.Native.*.so from CoreFX
• Version of muxer thingy: dotnet executable + MSBuild + NuGet + csc + vbc + fsc

The rest of the NuGet packages will be fetched by corerun nuget.exe install <package-name>. Is that right?

The managed code in platform-specific corefx nuget packages would be good accross all Linux distros as long as you got System.Native.*.so required by the nuget packages to the box.

Trube, but lets suppose some non-Linux SmartOS or some non-Unix like OS requiring a "managed" partial class implementation of System.IO.FileSystem.DriveInfo, would that require to come through nuget by same vendor? Can we reliably interpose the equivalent that kind of package from another vendor in nuget such that the end use when they consume S.I.F.D, on the said platform, they get the package published by someone else (and somehow approved by original vendor)?

[ericstj]

MSBuild + NuGet + csc + vbc + fsc

Those would all come from NuGet since (or be downloaded in a SDK zip) they are IL & not platform specific.

The rest of the NuGet packages will be fetched by corerun nuget.exe install . Is that right?

You could actually just use dotnet publish. If Alipine linux RID parents to linux RID it'll just 'exclude' all the native bits that aren't built in packages, but include all the corefx linux & unix specific implementations. This is what's already happening to build out the shared framework in core-setup. @piotrpMSFT I wonder if we could publish a shared-framework+SDK that is published for the Linux RID but missing the native bits. That way the only thing someone needs to do to make that work on a new distro is bring their own CoreCLR/Host/Shims. That solves the shared-framework case (standalone would be busted since that expects everything from Nuget) but it seems like a reasonable first step.

lets suppose some non-Linux SmartOS or some non-Unix like OS requiring a "managed" partial class implementation of System.IO.FileSystem.DriveInfo, would that require to come through nuget by same vendor?

Suppose this OS has a RID SmartOS that doesn't import the unix RID. That means that they wouldn't get the runtimes\unix\lib\netstandard1.3\System.IO.FileSystem.DriveInfo.dll file from that package. Vendor instead creates SmartOS.System.IO.FileSystem.DriveInfo package, which has runtimes\SmartOS\lib\netstandard1.3\System.IO.FileSystem.DriveInfo.dll. Today this only works for filling gaps, not overriding, so if SmartOS actually imported unix RID, you'd get two copies of the DLL /cc @davidfowl. In this specific example I discussed a "fat" package. If the package is split it doesn't have the override problem since the vendor could ship a runtime.json which lists the specific impl package that takes precedence on that RID.

[ericstj]

Here's an example of what that the lineup would look like to merge in native Alpine packages out of band: https://gist.github.com/ericstj/c9d79fdc37362377507bc5b03ab795f5

This can be in any package, so long as it's referenced by the app the bits will get merged in. I think this is important for the standalone scenario, but not necessarily the shared/CLI bring up as I mentioned above.

If we want to go down the route of building this lineup out of band I can show you how to create a .pkgproj that will produce this.

[schellap]

This is to unblock you, in the short-term. The end goal is to produce a .dotnet_stage0 (this is downloaded into the repo root by the build scripts in cli and core-setup) that will be used to build the CLI and Core-Setup repos.

First step after coreclr and corefx would be to build the muxer with the native compiler toolchain and CMake: Look for -G 'Unix Makefiles' here: http://dotnet-ci.cloudapp.net/job/dotnet_core-setup/job/master/job/debug_opensuse13.2_x64_prtest/90/consoleFull

Two parameters need to be slightly different: -DCLI_CMAKE_RUNTIME_ID:STRING=alpine.3.4.0-x64 and -DCLI_CMAKE_PKG_RID:STRING=alpine.3.4.0-x64.

The rest of the NuGet packages will be fetched by corerun nuget.exe install . Is that right?

You could actually just use dotnet publish. If Alipine linux RID parents to linux RID it'll just 'exclude' all the native bits that aren't built in packages, but include all the corefx linux & unix specific implementations. This is what's already happening to build out the shared framework in core-setup.

To get the pure managed assets, like @ericstj mentions above, you can use the following project.json and do a dotnet publish -r "alpine.3.4.0-x64".

{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": false
  },
  "dependencies": {},
  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "Microsoft.NETCore.App": {
          "version": "1.0.0"
        }
      },
      "imports": "dnxcore50"
    }
  },
  "runtimes": {
    "alpine.3.4.0-x64": { }
  }
}

With the managed and the native components from the CoreCLR/CoreFX and Core-Setup, you should be able to put together the Microsoft.NETCore.App layout for Alpine similar to what is available here: https://dotnetcli.blob.core.windows.net/dotnet/preview/Binaries/Latest/dotnet-ubuntu-x64.latest.tar.gz.

You might have to create a Microsoft.NETCore.App.deps.json -- I would suggest to hand edit this for bootstrapping from the ubuntu tarball.

This file also includes the RID fallback graph used by the muxer to select assemblies for the current RID, from a portable app layout which contains multiple RID folders (ls sdk/1.0.0-preview3-003171/runtimes). Add an entry for alpine similar to what @ericstj has shown in his gist. Code that does this is here: https://github.com/dotnet/core-setup/blob/a8211757bd4ea453313935e74ad6c0f1082bcfa6/build_projects/shared-build-targets-utils/Utils/SharedFrameworkPublisher.cs#L167). It would ultimately look something like:

  "libraries": {
    ...
  },
  "runtimes": {
    "alpine.3.4.0-x64": [
      "alpine.3.4.0",
      "alpine-x64",
      "alpine",
      "unix-x64",
      "unix",
      "any",
      "base"

and so on

At this point, this is a functional Shared Framework.

Next is to make CLI work with the framework. Most of the CLI is managed except few muxer friends (libhostfxr.so and libhostpolicy.so) but you built them above with CMake.

Last step is to use this .dotnet_stage0 to actually build Core-Setup to give an automated build which can then be used to build the CLI repo.

[ghost]

@ericstj, @schellap,

The information is quite helpful. I will make .dotent_stage0 for Alpine and then for Void soon. Thanks!

Suppose this OS has a RID SmartOS that doesn't import the unix RID.

Thanks for highlighting this @ericeil. By the analogy, AmigaOS won't inherit Unix whenever PowerPC architecture support will arrive to CoreCLR: https://www.power.org/ :)

[ghost]

@schellap, after building the muxer on alpine, I:

• downloaded and extracted the dotnet-ubuntu-x64.latest.tar.gz in core-setup/.dotnet_stage0 directory

• overwrote all the .a, .so files in .dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0 directory with corefx/bin, coreclr/bin and $HOME/muxer-build (except for corehost exe and libuv.so, not sure where to find those..)

• doctored the runtimes section in .dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/Microsoft.NETCore.App.deps.json like this:

  "alpine.3.4.0-x64": [
      "alpine.3.4.0",
      "alpine-x64",
      "alpine",
      "unix-x64",
      "unix",
      "any",
      "base"
    ],
    "alpine.3.4.0": [
      "alpine",
      "linux",
      "unix",
      "any",
      "base"
    ],
    "alpine-x64": [
      "alpine",
      "linux-x64",
      "linux",
      "unix-x64",
      "unix",
      "any",
      "base"
    ],
    "alpine": [
      "linux",
      "unix",
      "any",
      "base"
    ],

After that I commented out $REPOROOT/scripts/obtain/dotnet-install.sh --channel preview line in build_projects/dotnet-host-build/build.sh and ran core-setup/build.sh, it terminated with:

alp:~/core-setup$ ./build.sh
Restoring Build Script projects...
Did you mean to run dotnet SDK commands? Please install dotnet SDK from: 
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

Any ideas what am I missing?

[schellap]

At this point, this is a functional Shared Framework.

Next is to make CLI work with the framework. Most of the CLI is managed except few muxer friends (libhostfxr.so and libhostpolicy.so) but you built them above with CMake.

If you see the ubuntu bits here, there would be an $dotnet_root/sdk/ folder built in the CLI repo: https://dotnetcli.blob.core.windows.net/dotnet/Sdk/rel-1.0.0/dotnet-dev-ubuntu-x64.latest.tar.gz

[ghost]

Thanks @schellap. ATM, I am blocked by dotnet/coreclr#6211.

[sec]

@jasonwilliams200OK Thanks to your 'trip' I was also able to compile all for FreeBSD. Error I'm having right now is:
Unhandled Exception: System.BadImageFormatException: Could not load file or assembly '/usr/home/dotnet/core-setup/.dotnet_stage0/FreeBSD/sdk/1.0.0-preview3-003180/dotnet.dll'. An attempt was made to load a program with an incorrect format.

dotnet.dll is from ubuntu SDK - cli repo also requires this to build - shouldn't this be doable using coreclr ?

[ghost]

@sec, I am able to build dotnet muxer and finally executing dotnet restore command on Alpine Linux (i.e. CoreCLR initialization step passed). Trying to re-parse what @ericstj said about injecting runtimes in other PJs as ./build.sh on dotnet restore is giving errors on restoring the packages..

Regarding the System.BadImageFormatException, dotnet.dll should be fine as it is a MSIL assembly. Here is the procedure I followed:

On Windows (using PowerShell):

• Clone CoreCLR at $env:UserProfile/coreclr
• Execute coreclr/build.cmd to build the CoreCLR.
• Execute coreclr/build.cmd linuxmscorlib (in case of freeBSD, it should be freebsdmscorlib) to build:
  • coreclr/bin/Product/Linux.x64.Debug/mscorlib.dll
  • coreclr/bin/Product/Linux.x64.Debug/System.Private.CoreLib.dll
• Execute cd coreclr/bin/Linux.x64.Debug and then ../Windows.x64.Debug/crossgen mscorlib.dll to produce coreclr/bin/Product/Linux.x64.Debug/mscorlib.ni.dll

Now we have three dll files. We could have fourth one System.Private.CoreLib.ni.dll via crossgen, but that failse CoreCLR initialization (took me five hours to figure out what's going on :/ .. )

copy using scp from win to nix:

scp $env:UserProfile/coreclr/bin/Product/Linux.x64.Debug/* <user>@<ip>:~/copied-from-win/

On Unix-like:

• Clone CoreCLR at $HOME/coreclr and checkout to the exact commit hash as in Windows

• Clone CoreFX at $HOME/corefx

• Clone core-setup at $HOME/core-setup

• Download Ubuntu tar

  curl -O https://dotnetcli.blob.core.windows.net/dotnet/Sdk/rel-1.0.0/dotnet-dev-ubuntu-x64.latest.tar.gz
  mkdir -p core-setup/.dotnet-stage0/Linux
  cd core-setup/.dotnet-stage0/Linux
  tar xvfz ../../../dotnet-dev-ubuntu-x64.latest.tar.gz

• Build core-setup binary:

  mkdir $HOME/muxer-build && cd $HOME/muxer-build
  
  ../core-setup/src/corehost/build.sh --arch x64 --hostver 1.0.2-beta-000559-00 \
  --fxrver 1.0.2-beta-000559-00 --policyver 1.0.2-beta-000559-00 \
  --rid alpine.3.4.0-x64 --commithash 3c8ad46cb09d1ac87159b2cc17cb410afb835c9b

• Build coreclr: $HOME/coreclr/build.sh clang3.8 (on FreeBSD especially, I use clang38)

• Build corefx native: $HOME/corefx/build.sh native clang3.8 (on FreeBSD especially, I use clang38)

• Copy stuff:

  # from coreclr
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/corehost $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/libclrjit.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/libcoreclr.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/libcoreclrtraceptprovider.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/libdbgshim.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/libmscordaccore.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debuglibmscordbi.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debuglibsos.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debuglibsosplugin.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/System.Globalization.Native.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/coreclr/bin/Product/Linux.x64.Debug/corehost $HOME/core-setup/.dotnet_stage0/Linux/sdk/1.0.0-preview3-003180/
  
  # from corefx
  cp $HOME/corefx/bin/Linux.x64.Debug/Native/*.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  
  # from muxer-build
  cp $HOME/muxer-build/cli/fxr/libhostfxr.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/muxer-build/cli/dll/libhostpolicy.so $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/muxer-build/cli/exe/dotnet $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  cp $HOME/muxer-build/cli/fxr/libhostfxr.so $HOME/core-setup/.dotnet_stage0/Linux/host/fxr/1.0.1/
  cp $HOME/muxer-build/cli/exe/dotnet $HOME/core-setup/.dotnet_stage0/Linux/
  cp $HOME/muxer-build/cli/fxr/libhostfxr.so $HOME/core-setup/.dotnet_stage0/Linux/sdk/1.0.0-preview3-003180/
  cp $HOME/muxer-build/cli/dll/libhostpolicy.so $HOME/core-setup/.dotnet_stage0/Linux/sdk/1.0.0-preview3-003180/
  
  # from copied-from-win
  cp $HOME/copied-from-win/*.dll $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/
  
  # from pkg
  pkg install libuv
  sudo find / -name "libuv.so"
  # and copy the one from packages to $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/

• Disable dotnet-install in one of the core-setup script:

  diff --git a/build_projects/dotnet-host-build/build.sh b/build_projects/dotnet-host-build/build.sh
  index 919e694..2ca046b 100755
  --- a/build_projects/dotnet-host-build/build.sh
  +++ b/build_projects/dotnet-host-build/build.sh
  @@ -94,7 +94,7 @@ done < "$REPOROOT/branchinfo.txt"
  [ -d "$DOTNET_INSTALL_DIR" ] || mkdir -p $DOTNET_INSTALL_DIR
  
  
  -$REPOROOT/scripts/obtain/dotnet-install.sh --channel preview
  +#$REPOROOT/scripts/obtain/dotnet-install.sh --channel preview

• Replace all instances of ubuntu.14.04-x64 in $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/Microsoft.NETCore.Apps.json with alpine.3.4.0-x64 and debian-x64 with alpine-x64, then add the following in runtimes section:

  "alpine.3.4.0-x64": [
      "alpine.3.4.0",
      "alpine-x64",
      "alpine",
      "linux-x64",
      "linux",
      "unix-x64",
      "unix",
      "any",
      "base"
    ],
    "alpine.3.4.0": [
      "alpine",
      "linux",
      "unix",
      "any",
      "base"
    ],
    "alpine-x64": [
      "alpine",
      "linux-x64",
      "linux",
      "unix-x64",
      "unix",
      "any",
      "base"
    ],
    "alpine": [
      "linux",
      "unix",
      "any",
      "base"
    ],

(I also removed and orphaned alpine.3.4.0-x64 entry from under mint linux)

• IMPORTANT: rename or remove $HOME/core-setup/.dotent_stage0/Linux/Microsoft.NETCore.App/1.0.0/System.Private.CorLib.ni.dll (append with _ etc.) and change its only occurrence of System.Private.CorLib.ni.dll in $HOME/core-setup/.dotnet_stage0/Linux/shared/Microsoft.NETCore.App/1.0.0/Microsoft.NETCore.Apps.json to System.Private.CorLib.dll. (as mentioned earlier, this took a while to figure this bit out..)

This is pretty much it, after that I executed $HOME/core-setup/build.sh or $HOME/core-setup/.dotent_stage0/Linux/dotnet restore to get it passed coreclr_initialize phase.

[jkotas]

'/usr/home/dotnet/core-setup/.dotnet_stage0/FreeBSD/sdk/1.0.0-preview3-003180/dotnet.dll'. An attempt was made to load a program with an incorrect format.
dotnet.dll should be fine as it is a MSIL assembly

BadImageFormatException can be caused by trying to run ReadyToRun .dll native compiled for Linux on FreeBSD. Make sure to copy the MSIL assembly that is not ReadyToRun compiled.

[mar10m3n3z35]

Thanks @janvorli

I tried using your docker file however when I tried to run my application in it it gave me an error

container_linux.go:247: starting container process caused "exec: "dotnet": executable file not found in $PATH"

ENV DOTNET_VERSION 2.0.0-preview2-25407-01
ENV DOTNET_DOWNLOAD_URL https://dotnetcli.blob.core.windows.net/dotnet/Runtime/$DOTNET_VERSION/dotnet-runtime-$DOTNET_VERSION-linux-x64.tar.gz
#ENV DOTNET_DOWNLOAD_SHA 72AA9ABAE8BC818EEB742AFFB943D6AF33B009F84696E6DE7C5316B8975FCC9B4303CB0B80652727BB1FFEE1A025E0C7A43CFE1771D11FE6DEE2D36B002A7EDC

RUN curl -SL $DOTNET_DOWNLOAD_URL --output dotnet.tar.gz
#&& echo "$DOTNET_DOWNLOAD_SHA dotnet.tar.gz" | sha512sum -c -
&& mkdir -p /usr/share/dotnet
&& tar -zxf dotnet.tar.gz -C /usr/share/dotnet
&& rm dotnet.tar.gz
&& ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet

then it gave me error
standard_init_linux.go:178: exec user process caused "no such file or directory"

so I added

RUN /bin/sh -c "apk add --no-cache bash"

RUN ALPINE_GLIBC_BASE_URL="https://github.com/sgerrand/alpine-pkg-glibc/releases/download" &&
ALPINE_GLIBC_PACKAGE_VERSION="2.25-r0" &&
ALPINE_GLIBC_BASE_PACKAGE_FILENAME="glibc-$ALPINE_GLIBC_PACKAGE_VERSION.apk" &&
ALPINE_GLIBC_BIN_PACKAGE_FILENAME="glibc-bin-$ALPINE_GLIBC_PACKAGE_VERSION.apk" &&
ALPINE_GLIBC_I18N_PACKAGE_FILENAME="glibc-i18n-$ALPINE_GLIBC_PACKAGE_VERSION.apk" &&
apk add --no-cache --virtual=.build-dependencies wget ca-certificates &&
wget
"https://raw.githubusercontent.com/andyshinn/alpine-pkg-glibc/master/sgerrand.rsa.pub"
-O "/etc/apk/keys/sgerrand.rsa.pub" &&
wget
"$ALPINE_GLIBC_BASE_URL/$ALPINE_GLIBC_PACKAGE_VERSION/$ALPINE_GLIBC_BASE_PACKAGE_FILENAME"
"$ALPINE_GLIBC_BASE_URL/$ALPINE_GLIBC_PACKAGE_VERSION/$ALPINE_GLIBC_BIN_PACKAGE_FILENAME"
"$ALPINE_GLIBC_BASE_URL/$ALPINE_GLIBC_PACKAGE_VERSION/$ALPINE_GLIBC_I18N_PACKAGE_FILENAME" &&
apk add --no-cache
"$ALPINE_GLIBC_BASE_PACKAGE_FILENAME"
"$ALPINE_GLIBC_BIN_PACKAGE_FILENAME"
"$ALPINE_GLIBC_I18N_PACKAGE_FILENAME" &&

rm "/etc/apk/keys/sgerrand.rsa.pub" &&
/usr/glibc-compat/bin/localedef --force --inputfile POSIX --charmap UTF-8 C.UTF-8 || true &&
echo "export LANG=C.UTF-8" > /etc/profile.d/locale.sh &&

apk del glibc-i18n &&

rm "/root/.wget-hsts" &&
apk del .build-dependencies &&
rm
"$ALPINE_GLIBC_BASE_PACKAGE_FILENAME"
"$ALPINE_GLIBC_BIN_PACKAGE_FILENAME"
"$ALPINE_GLIBC_I18N_PACKAGE_FILENAME"

ENV LANG=C.UTF-8

Now I get Error

dotnet: /usr/lib/libstdc++.so.6: no version information available (required by dotnet)

Please help.

[janvorli]

@mar10m3n3z35 I am sorry, I was probably not clear. This Docker file creates environment for building native parts of coreclr / corefx / core-setup repos, not for running dotnet tools. There is no version of dotnet core tarball that can work on Alpine (due to its usage of MUSL library) yet. Fixing the build is just the first step towards that.

[imacks]

In the meantime, is it possible to build on alpine with glibc? alpine-pkg-glibc

[qmfrederik]

@imacks I think that coreclr master should compile on Alpine, since dotnet/coreclr#13052 got merged a while ago.

[kbatman37]

+1

Do we know if there is anyone is actively working towards this?

[Petermarcu]

@janvorli is looking at getting everything going on Alpine again.

[janvorli]

@kbatman37 yes, I am actively working on that. The native parts builds were already fixed for Alpine some time ago, now I am working on making dotnet core on Alpine work end to end.

[day01]

@janvorli Will it be available at docker registry as microsoft official image? (https://hub.docker.com/r/microsoft/dotnet/)

[janvorli]

I was not thinking about the docker container yet, but I don't see a reason why it would not be there.

[toddschilling]

Yes please!

[JasonMorgan]

Hey just wanted to see if there was any movement on this?

[shaggygi]

Noticed this yesterday... dotnet/corert#4552 (comment)

[Petermarcu]

@janvorli is extremely close to having builds for Alpine. I dont think any of the builds are available yet but I am guessing he's days away.

[murbanowicz]

@Petermarcu @janvorli when you will success with builds for Alpine, will they be available as tags within main docker image for .net core?

[MichaelSimons]

@murbanowicz - yes the plan is to create Apline based Docker images for .NET Core. dotnet/dotnet-docker#22 tracks this work.

[Petermarcu]

@MichaelSimons I think we have a build you can pull into a container now.

[MaximRouiller]

AWESOME!

[ghost]

From dotnet/dotnet-docker-nightly#480

Note: self-contained apps are not yet working e2e therefore the test case for the runtime-deps is disabled.

Where can we track the concrete remaining work preferably in the form of checklist?

Bit of a retrospective ..
As an avid developer looking to find answer for "what's the status of dotnet core on Alpine linux" in open-dotnet world, I was nothing but lost: Looking at the amount of cross-linking happened on GitHub due to Alpine Linux in PowerShell and dotnet repos, it deserved a solid checklist at a very very early stage in one of the repos: corefx, coreclr, core or home.

Either we were getting vague replies like "Jan is working on it", "Jan is extremely close" or pointer to this quite-broad issue https://github.com/dotnet/coreclr/issues/917 with over 240+ comments and does not provide a concrete definition of "remaining work" at all.

This would have helped the lack-of-clarity issues and you could have gotten way more contributions by just having information put in one place (a good example: https://github.com/dotnet/coreclr/issues/5851, solid, to-the-point "check-list").

[janvorli]

@kasper3 right, I am sorry for not tracking the work in an easily discoverable way. I have just created dotnet/core#1076 to fix that. Please let me know if you'd like to see more detail added there.

[MaximRouiller]

Linking announcement here:

dotnet/announcements#49

[ghost]

@janvorli, can this be closed since Alpine support has landed in 2.1? For Amiga and others, more specific issues can be opened separately.

[ghost]

@jkotas, maybe the title of this issue can be renamed to Alpine Linux, instead of multiple operating systems. This is the most commented opened issue in the repo, which, i think, can safely be closed (after title renaming).

[jkotas]

Agree. Thanks