Supporting a broader base of platflorms.

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:

@tracker1

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

@phillipkent

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

@tracker1

@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!

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.

@ajensenwaud

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

@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!

@josteink

@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.

@tracker1

@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.

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

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?

@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.

@taylorjonl

@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.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

It looks the conversation on this issue concluded a long time ago.

Navigation Menu

Repository navigation

Supporting a broader base of platflorms. #4173

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Supporting a broader base of platflorms. #4173

Description

Activity

richlander commented on Apr 24, 2015

ghuntley commented on Apr 24, 2015

josteink commented on Apr 25, 2015

ajensenwaud commented on Apr 25, 2015

ghuntley commented on Apr 26, 2015

josteink commented on May 3, 2015

tracker1 commented on May 5, 2015

richlander commented on May 6, 2015

ajensenwaud commented on May 8, 2015

taylorjonl commented on Dec 12, 2015

taylorjonl commented on Dec 12, 2015

bcantrill commented on Dec 15, 2015

27 remaining items

dotnet-policy-service commented on Feb 10, 2025

dotnet-policy-service commented on Dec 5, 2025

richlander commented on Dec 5, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions