search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.03k stars 4.67k forks source link

Supporting a broader base of platflorms. #4173

Open tracker1 opened 9 years ago

tracker1 commented 9 years ago

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:

richlander commented 9 years ago

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: dotnet/runtime#4039.

/cc @janhenke, @josteink

ghuntley commented 9 years ago

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 dotnet/runtime#4098

josteink commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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

ghost commented 9 years ago

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

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):

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

@ghuntley, I think it's now or never! :sunglasses: 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. :zap:

josteink commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

@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 commented 9 years ago

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 commented 8 years ago

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?

ghost commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

ghuntley commented 8 years ago

Here's some snippets from a conversation on irc.freenode.net #smartos.

10:16 AM <ghuntley> good morning, who here would like to the .NET Virtual Machine (CoreCLR) running on SmartOS/Solaris/Illumos? 
10:16 AM <rmustacc> There are probably a bunch of folks who like to see it running natively.
10:17 AM <rmustacc> There are some who are getting it going via lx right now.
10:17 AM <rmustacc> richardkiene1 might know some folks.
10:17 AM <richardkiene1> ghuntley: Aye
10:18 AM <richardkiene1> In fact I've already done a bit of work there :)
10:18 AM <rmustacc> richardkiene1: On running natively?
10:18 AM <richardkiene1> If you're willing to use an LX branded zone, it already works great
10:18 AM <richardkiene1> rmustacc: Yeah I started building it the other day, but got distracted with the LX stuff

10:18 AM <ghuntley> @richardkiene1 have you seen the following github issue? https://github.com/dotnet/coreclr/issues/803
10:19 AM <richardkiene1> ghuntley: Indeed, I'm one of the people currently working on that with Bryan
10:19 AM <rmustacc> ghuntley: Looks like Bryan did.
10:19 AM <richardkiene1> taylorjonl's gist works great actually, but Clang is busted in the current pkgsrc
10:20 AM <richardkiene1> You can hack up your directory structure until the cows come home and it'll start building
10:20 AM <richardkiene1> No clue if it finishes yet, but I don't think we're really that far from making it work on native SmartOS

10:20 AM <ghuntley> alright sweet, I was dropping in here to find support from people with domain knowledge of smartos and was going to funnel them to help out Bryan. :-)
10:20 AM <rmustacc> ghuntley: Haha, well, Bryan has more domain knowledge than most of us. ;)
10:21 AM <rmustacc> ghuntley: But if you are working on it with folks, I'd just say that if you ever hit a technical question with this, just come up here and ask.

10:21 AM <richardkiene1> It needs some updating, but the blocker right now for SmartOS is Clang
10:21 AM <nahamu> jperkin said that 2015Q4 pkgsrc will have a working clang.

10:22 AM <richardkiene1> ghuntley: We're actually in contact with the CoreCLR team :)
10:22 AM <richardkiene1> Everyone is quite open to working together, so the dream is alive ;)

10:26 AM <rmustacc> So, is libunwind a requirement?
10:26 AM <rmustacc> And what exactly are they trying to get from libunwind?
10:27 AM <rmustacc> Because there is no illumos port of libunwind.
10:27 AM <rmustacc> Though they're not the first to want it.
10:27 AM <rmustacc> We'll have to work through the details though.

10:29 AM <ghuntley> Rich Lander is the guy you want to be directly speaking with at MSFT, he's super interested in seeing how this progresses -> https://twitter.com/runfaster2000/status/676899041670729728
10:29 AM <richardkiene1> ghuntley: I already am, actually :)

10:58 AM <rzezeski> rmustacc: I’m fairly certain Abel Mathew ported libunwind to illumos. I believe for use with Backtrace (http://backtrace.io/).
11:14 AM <rzezeski> rmustacc: Ya know, I’m not sure what the deal is with the source. I just remember meeting him at illumos day and him mentioning a port of libunwind to illumos.
ghost commented 8 years ago

Official -> https://github.com/joyent/libunwind :smile:

richardkiene commented 8 years ago

@jasonwilliams200OK The original repo was setup and blown away, sorry if anyone was already watching it. Until it is ready, the work will be done on the OS-5039 branch. You can also track the ticket for the libunwind port at https://smartos.org/bugview/OS-5039

taylorjonl commented 8 years ago

I created a pull request to get the build to a point where we need libunwind to go further.

https://github.com/dotnet/coreclr/pull/2428

4 of the CI builds failed but they were for reason like failing to clone the repo and a such, not related to my changes which were pretty small. Do the CI builds have to succeed for a pull request to be merged?

krytarowski commented 8 years ago

I can help with SmartOS port - I'm doing right now the NetBSD support. Initial prerequisites are libunwind and LLDB. I ported base support of LLDB and pushed libunwind to pkgsrc both for NetBSD.

For doing SmartOS port now, I would need to do it during business hours.. so unless it can happen I can only focus on evening hours for NetBSD.

On the other hand I will be helping to @jperkin and @bcantrill with mono.

BenjiZombie commented 7 years ago

Is there any updates on this, especially porting to SmartOS native zones? What are the stoppers? I'd like to help.

josteink commented 7 years ago

@BenjiZombie I think the main thing lacking is a concentrated effort, and preferably a team effort.

While getting CoreCLR building probably won't be too hard (it's mostly native stuff and thus no circular dependencies).

Where you're bound to hit a few tough learning-curves is with getting CoreFX built for your platform of choice. Since .NET Core transitioned over to being self-bootstrapped, getting a bare minimum self-hosting SDK to build is required before you can build the rest of the framework.

Even as someone who tried to follow this repo since it was pretty new, I find that pretty daunting (and I eventually gave up on it, when trying to get the FreeBSD momentum back together).

The good news is that last time I checked (6 months or more ago) someone were looking into ways to try to ease that pain (in that case with regard to Fedora 25 iirc), but I'm not sure if anything has actually happened.

@richlander Any news on that?

Note you may also to meet issues with some external (libunwind, mono, llvm, whatever) and might need to get those resolved before you can move on. In that case, having some strings to pull with the relevant maintainers can also be beneficial.

Best of luck :)

krytarowski commented 7 years ago

Porting .NET to platforms without LLDB is questionable. No easy way to debug build failures in managed code runtime.

I might try to port Illumos style core(5) files to LLDB to workaround it.. and then on other system like NetBSD we could read it. But first things first, I still have TODO tasks on my native platform (NetBSD) in this debugger.

franksinankaya commented 4 years ago

Just an FYI. I have been working with @jkotas , @janvorli and @am11 over a year now.

We have recently completed GCC support on master branch. The hope is to reach out to other platforms where GCC is the only supported compiler.

krytarowski commented 4 years ago

This is great news!

am11 commented 4 years ago

Also CoreFX builds with -gcc.

For Solaris-likes, arch: x86-64:

In another news, LLVM 6 toolchain (with still missing LLDB) is now present in pkgsrc for SmartOS.

However, I have used gcc so far in that system coreclr/build.sh -gcc. will revisit SmartOS build few days from now, once CoreCLR, CoreFX and CoreSetup repos are merged as unified runtime repo. Hoping that CoreSetup will get gcc-love as a byproduct of that (otherwise we will need to gcc-bootstrap it separately).

krytarowski commented 4 years ago

Are there plans to add support for SmartOS in LLDB? .NET was my original intention to start working on LLDB for NetBSD.. it takes now like 4 years, but we are getting now pretty close.

am11 commented 4 years ago

Are there plans to add support for SmartOS in LLDB?

From Joyent's side, I am following this issue: https://github.com/joyent/pkgsrc-joyent/issues/35. I am not sure if someone from SmartOS community has been contributing to LLDB code base; but generally Solaris platform is listed in LLDB sources at various places [1].

Note that GDB can also be used for retrospective core dump analysis for native and managed parts of .NET application. GDB, in general, does not provide a high-level extensibility model like LLDB. A low'ish-level MI interface is available, which is a major feat to support as per: https://github.com/dotnet/diagnostics/issues/272. Haven't tried (yet). :)

am11 commented 4 years ago

@tracker1, @jkotas, since the remaining work here is about Solaris (Alpine and FreeBSD work was done separately) and the thread is heavily invested on Solaris related discussion, I am using this one as tracking issue. Can we reword the title with Solaris and add os-solaris label?

krytarowski commented 4 years ago

I object. I'm working actively on the NetBSD port, but currently on the Operating System layer. We have just finished LLDB to the point of importing it to the basesystem. There is ongoing work on reworking of synchronization primitives that will help in .NET as well.

Meanwhile, keep your good work on Solaris.

am11 commented 4 years ago

@krytarowski, I only meant that the title of this issue is too broad to tackle something meaningfully. We have had specific issues for FreeBSD, NetBSD and other operating systems. I am proposing this one can be repurposed for Solaris, one particular operating system or simply closed.

am11 commented 4 years ago

I have opened #34944 to track Solaris port work.

krytarowski commented 4 years ago

I propose to just open a dedicated issue for Solaris and be done.

tracker1 commented 4 years ago

@am11 thank you... I do agree, that if you want to track a specific OS, then a specific issue should be in place...

tracker1 commented 4 years ago

I added a link to all the os- prefixed labels to the main description above.