[WIP - Do not merge] Alpine Linux Port

[benpye]

This currently gets PAL to compile on Alpine Linux, a musl and busybox based distribution. Toward #917 .

I would like some feedback on the method used to set distribution, the build script needs to know as certain libraries for example lttng are unavailable on musl, and whilst coreclr treats them as dependencies, features can be disabled to stop their use. Additionally my securecrt changes are a hack to get compilation working, what would the correct solution to those typedefs be? And I assume I should correct the reason the define is needed, without __GNUC_VA_LIST there are missing symbol errors.

[ghost]

Thanks @benpye!
@krytarowski, do we know anyone familiar with musl or Alpine in general who can provide some feedback on this work item? Would really help us move forward in this dimension. :)

[benpye]

Last I checked @jasonwilliams200OK this was functional on Alpine though likely regressed now. I actually got libunwind packaged for Alpine too. Any ideas for answers to my previous questions would very much be appreciated and I'd happily try and incorporate them.

[krytarowski]

I think I recall only one NetBSD user knowing Alpine - @fcambus.

[ghost]

Thanks @krytarowski. Hopefully we get some inputs from @fcambus. Pinging @ncopa from Alpine port project (https://github.com/alpinelinux/aports) to seek help for Ben's question. :)

If someone is wondering, here is another reason to encourage Alpine Linux as Docker is probably switching to Alpine Linux due to its performant and significantly less memory consumption nature http://www.eweek.com/virtualization/slideshows/alpine-linux-goes-all-in-for-docker.html. So running CoreCLR on such a Docker container natively would be considered a great deal!

Here is an open issue for lldb port by @matthewvalimaki: https://bugs.alpinelinux.org/issues/4966.

[krytarowski]

Do you really want to define it for NetBSD?

coreclr/src/pal/src/loader/module.cpp

Line 1625 in 49f39af

shortAsciiName = "libc.so";

[benpye]

This was a quick change to get it working, not sure of the correct path forward.

[krytarowski]

In general I don't like this code. Can you use a saner detectable libc library on Alpine? Perhaps go for rump unikernel and use NetBSD library stack on Alpine it will be way cleaner.

PS. I know it's not tested yet, but it's a way to make CoreCLR compatible with POSIX-like systems more easily.

[ncopa]

In general I don't like this code.

+1

However, it gives a hint on what needs fixing, but I don't think this should be merged as-is.

In general, it is better to test for features than test for platforms, and then in the code do something like:

#if HAVE_FEATURE_THIS
...
#elif HAVE_FEATURE_THAT
...
#else
/* fallback to some standard, like POSIX */
...
#endif

[ghost]

Thanks for the comments guys. I am configuring Alpine Linux 3.3.1 at the moment. When i will get clang and dependencies in place, will try to feature detect to replace those hardcoded ifdef's, the way it is done at other places in coreclr. Stay tuned! :)

@ncopa, is anyone working on porting lldb to Alpine at the moment? @krytarowski, ported lldb recently to NetBSD via pkgsrc, so we can probably get some collaboration in this area. :)

[ellismg]

@jasonwilliams200OK You may be able to unblock yourself by making the LLDB requirement optional when LLDB is not installed. We do this on OSX. We won't build the SOS plugin which is not great long term because it's helpful in debugging the runtime but it's not a blocker for getting the runtime to boot.

[ghost]

Thanks @ellismg. I will use Ben's code from this PR where ldd is already disabled for Alpine.
While I was doing patches for CoreFX native, I started to work on Alpine and able to build 50% so far. Some networking stack modules use different headers and feature detection is bit tricky as while Alpine is categorized as Linux by CMake, most of the lowlevel headers are different (especially linux/*.h ones).

[ghost]

@ncopa, I am able to build 97% of CoreFX (the .NET Core base libraries repo which has comparatively a small native code base) on Alpine with this patch https://github.com/jasonwilliams200OK/corefx/commit/63e61a36e9585255844f6c141b39d4214bd53634. Once I will get that working 100%, I will try to contribute to CoreCLR (which is the actual runtime).

To perform a quick compile:

# in alpine ash, bash or sh
git clone https://github.com/jasonwilliams200ok/corefx -b alpine-linux-port --single-branch
cd corefx
./build.sh native  # requires cmake, libopenssl and couple of other dependencies
                   # which i found using `apk search`

The remaining portion is where the networking layer of CoreFX relies on netlink headers, for example nlmsghdr is used from netlink.h header, which are missing from . At this point, can I get some help to figure out the remaining issues? Or better yet can we add CoreFX to aports and fix the remaining build issues there and then upstream the patches?

[ghost]

With https://github.com/jasonwilliams200OK/corefx/commit/337f5ed4927f210a6b1b5bbda70792da53d7cd73 patch, CoreFX' System.Native now builds fully on Alpine Linux.

Thanks to @ncopa for pointing me out that we need apk add linux-headers to get netlink headers (chatted through IRC freenode#alpine).

Thanks to @GyrosGeier for pointing me out that there is a better (non-cmake) way to detect type disparities across OSes implementations of same struct member on freenode#cmake (this partial patch https://github.com/jasonwilliams200OK/corefx/commit/939fc312474afee11707e7759f6a491587b40510).

I will also try to refactor the type disparities across CoreFX as a general purpose TypeProvider with all the required decltypes and a template-based GetResolvedTypeValue(T), as @nguerrera once envisioned. :)

Now it's time to up-streaming smaller patches to CoreFX repo for musl-libc support! ⚡

[nguerrera]

I will also try to refactor the type disparities across CoreFX as a general purpose TypeProvider with all the required decltypes and a template-based GetResolvedTypeValue(T), as @nguerrera once envisioned. :)

I'm actually not sure what you're referring to here. Neither TypeProvider nor GetResolvedTypeValue ring any bells...

[ghost]

@nguerrera, actually those names are my own, I was referring to this dotnet/corefx#3479 (comment). Sorry for the confusion. 😄

[benpye]

Added some comments to address some issues. As you may of noticed this was sort of a dump of my current progress, unfortunately I haven't moved forward with it since. Most of the issues above are things we need to either test for, or toggle at build time some how.

[ghost]

@benpye, @jkotas, this can be closed now, as all the patches for Alpine Linux are upstreamed and CoreCLR fully builds (modulo lldbplugin): #917

[jkotas]

@jasonwilliams200OK @benpye Thanks a lot to plowing through all the Alpine issues!