Supporting a broader base of platflorms.

[tracker1]

Just curious, given the support given towards FreeBSD in addition to Linux how difficult it would be to getting CoreCLR working with Solaris and derivatives? Also, it may be worth testing out Linux distros that use core libraries that aren't glibc (such as Alpine, etc).

OS Specific Labels:

• Alpine Linux
• Android
• FreeBSD OS
• Apple iOS
• Linux OS (any supported distro)
• macOS aka OSX
• NetBSD OS, currently not officially supported
• SunOS, currently not officially supported Tracking issue for illumos and Solaris x86-64 port work #34944
• Tizen OS
• Apple tvOS
• Windows IoT
• Nano Windows SKU
• WSL - Windows Subsystem for Linux
• Windows
• Unsupported OSes

[richlander]

Hi @tracker1. Thanks for the interest in the project.

You can look at the closed PRs for FreeBSD to see what the "FreeBSD Port Team" had to do get to this point. I'm sure that the port team members would be happy to comment as well.

https://github.com/dotnet/coreclr/pulls?q=is%3Apr+is%3Aclosed+label%3AFreeBSD

We're happy for other folks to bring up other OSes. The model that we used for FreeBSD worked really nicely. A team of enthusiasts formed a "Port Team" to bring up the port together. A larger community, including MSFT folks helped them a bit, too. See the formation of the FreeBSD Port Team: #4039.

/cc @janhenke, @josteink

[ghuntley]

Thanks to @phillipkent from Interroute who has comped vmware based infrastructure for the developers it is totally possible to spin up environments for Solaris/OpenIndiana/SmartOS. The real crux/pain in getting those operating systems working is the CICD infrastructure and doing builds on environments that don't work on the platform yet that the CICD runs on. /cc @mmitche anyway around this hurdle?

See issue #4098

[josteink]

@tracker1 Basically porting something like .NET isn't going to be easy, and you're bound to hit at least one issue you wont be able to solve yourself. If you're the only guy working on your port, that will be it. That's the death-sentence. You're done.

I would take @richlander's advice and try to get a team/group going. You can try to create an issue, like @janhenke did and gather interested parties to it through any means you find reasonable (reddit, irc, whatever).

When you see that you have sufficient people interested and momentum to get going, that's when I would make the decision to go, or if it doesn't bode well, create a prive fork where you see how far you can get on your own.

Creating "good" pull-requests for mainline coreclr does involve quite a bit of extra work as opposed to just getting the build going yourself, so if you're not sure you have a team which can pull through, I don't think it would be wise to spend your limited energy on matters like that yet.

This is what @ajensenwaud and others did for FreeBSD, before @janhenke summoned us to try to do it "for real". I think it worked out well.

With that said: Best of luck to you!

[ajensenwaud]

I am currently setting up an OpenIndiana instance on Interoute where we can do a couple of initial tests. I am not a Solaris expert so might not be able to support the port effort, but I will do my best.

[ghuntley]

@ajensenwaud solaris/aix/hpux sysadmin (and potentially physical hardware) is something I can aide with when/if needed.

While I agree with @josteink's idea of DIY and acknowledge the inherent complexity of this project, I have slightly different opinion. 💡

IMO, the more OS coverage is assured at this early stage and coreclr source encounter many many environments and low-level runtimes, the better it is for xplat and robust base. Otherwise the bugs will grow and the *nix support will be impartial; focused more on one variant than the other.

Having said that, please also consider targeting Alpine Linux and Lilblue Linux. The older version of former and the current version of latter make use of µclibc, while the latest version of Apline uses musl libc. I particularly mentioned those as they do not use glibc (https://github.com/andikleen/glibc) but a light-weight performance-conscious C runtimes. If someone has enough experience, I would suggest to test coreclr against dietlibc as well.

Secondly, can you please visit these distributions/flavors once, which might already be supported, and add any differencing steps for { building, installing, consuming } into the docs (or mention them in docs anyway, to declare that you acknowledge those distributions here):

• Arch
• Suse
• Gentoo
• Fedora
• Alpine
• Mint

.. is something I can aide with when/if needed.

@ghuntley, I think it's now or never! 😎 if you have access to Solaris, and the initial try failed, could you please open a separate issue so we know it is being tackled somewhere and the current stopper is such and such. Maybe someone else run into it propose a solution and things move forward rather swiftly. ⚡

[josteink]

@jasonwilliams200OK You have some good feedback there. My advice was just meant as that, and not as some general "law" which must be followed. Not that I'm in any position to suggest or enforce such anyway :)

I think the coreclr contribution-guidelines are very clear about the point that ports are welcome, and I'm sure whatever route you chose, your commits will be welcomed.

As for Linux-support across distros, I think that's a very good point and very good idea. IMO too many projects are somewhat Ubuntu-centric these days, and it probably wouldn't take much work mapping out and documenting what other distros are supported, and what work is required.

I'd limit my initial efforts to the "main" distros, and not derivatives (like Mint), but this is obviously stuff which can be discussed.

So for this part, I think the best would be to go and make a separate issue for it. That way it can be tracked properly, and closed when completed. Since it was your idea, you deserve the credits for it, so I think you should go and make it :)

With that said: Sorry for hijacking the thread with Linux-stuff. Back to Solaris/OpenIndiana-related matters!

[tracker1]

@josteink Agreed on many projects being Ubuntu centric... especially in the light of how widespread docker use is becomming. I've been more aware of how big some of the base images for projects are getting, and as @jasonwilliams200OK mentioned Alpine, I've been doing some testing of a few projects under it (specifically for docker use).

@richlander I appreciate your feedback, and I'm not myself actually running OpenIndianna/Solaris, I just want to support making this effort as portable as possible, because it makes things closer to anti-lockin. I tend to run my deploys to Linux lately (still supporting some Windows), but would like the option to target other platforms in the future if they are a good fit. Given how much of a baseline this project is for future .Net development, keeping it very broad is imho a good idea.

In light of how much MS has supported making sure that libuv/ev work in windows, it's easy to see a similar effort here in making this work in as many places as possible.

[richlander]

@tracker1 It's a good sentiment, and we're happy for people to help us to that end. We've got our hands full with our current priorities, which as @josteink points up, we've documented. We've got a tight schedule to meet, and a lot of customers who want .NET Core on Linux ASAP, so we don't have the luxury of going super broad at this point.

I really like the approach that has been taken with FreeBSD. If folks want to go that route, we'll support you.

[ajensenwaud]

Hi all,
I have set up a SmartOS instance. Please let me know if you are keen to get an account on the box so we can start porting the code to illumos/Solaris.

Cheers

Anders

[taylorjonl]

I am trying to get this to build in a SmartOS zone, I am documenting the journey here:

https://gist.github.com/taylorjonl/df65cea78beaa7e6b16e

I have it to a point where cmake tries to test the compilers but it fails with:

/opt/local/gcc48/lib/gcc/x86_64-sun-solaris2.11/4.8.4/amd64/crtend.o: open failed: No such file or directory

This path does not exist... The file in question is located at this path:

# find / -name crtend.o
/opt/local/gcc47/x86_64-sun-solaris2.11/lib/32/crtend.o
/opt/local/gcc47/x86_64-sun-solaris2.11/lib/crtend.o

I am not a cmake expert, how do I influence the directory it looks at?

@taylorjonl, since you are building with clang, it should be looking in /lib/clang/3.5/crtend.o assuming 3.5 is the version of clang you are building with (?)
Additionally, you will need to install lldb lldb-dev and libunwind. See the related issue: http://stackoverflow.com/q/29619399.

how do I influence the directory it looks at?

It shouldn't be required if you have packages installed. But for testing purpose, you can do something like this: https://github.com/dotnet/coreclr/pull/1666/files:

include_directories(/opt/local/gcc47/x86_64-sun-solaris2.11/lib) # without SYSTEM

Note that this shouldn't be the fix because coreclr is building with Clang not GCC and pretty soon you will get some other error. The real solution is to make sure you have all the dependencies installed before moving on to build step.

[taylorjonl]

@jasonwilliams200OK I checked /opt/local/lib/clang/3.6.2 but it only includes an include folder, not those object files. I also couldn't find an lldb-dev or libunwind package in the ports library that SmartOS uses for packages, I was going to deal with that issue when I got further in the process.

For now I may just build my own version of llvm/clang, see what files it installs but when I installed llvm/clang it pulled in those object files to that gcc directory through a gcc library package. I think this is by design but I will have to work with the maintainer of that package to find out why and how to get around this issue.

[bcantrill]

@taylorjonl, @jperkin and/or @mamash from Joyent might be able to give you a hand. We've been running CoreCLR on Ubuntu on SmartOS via LX, but we'd like to see a native port as well.